From nobody Mon Nov 2 06:48:00 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE103A10FD for ; Mon, 2 Nov 2020 06:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOClprB2z6IF for ; Mon, 2 Nov 2020 06:47:58 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 E35963A10FC for ; Mon, 2 Nov 2020 06:47:57 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id a65so9403382qkg.13 for ; Mon, 02 Nov 2020 06:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivm3w8z2HrFxlFEnret3bG+R2P+rk9PTWAKSv+2lBPQ=; b=M+gA8z6goI32yn6G/eV1WKT1nuwjEBDIQ8v2cigJ9UohZd32Ya6VuqVkUt7OT9dDBW GkkaXm0OTVjAlrgdOw2cafvACPwh3Z2gtQaKzLPEDEmtT8IdaB7wsJLiP4RKKh/JIr8h F1tT6RjLvuMnrG1JyGEVLVYwtaWUwJAVE5fvY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ivm3w8z2HrFxlFEnret3bG+R2P+rk9PTWAKSv+2lBPQ=; b=BYfm4To9uZoySE9w1ilRmmgGwtKAh7Dx9qI/E8z0PZ4WUPPGcZjIQuHZDYyHXvHTgY dPW+ov7jr8C9u7NXUoF2hU9N2wd+mwZc4S1dz6fq4uiRQSy8iMYszt0hTcYaQGVJd8Kw w+cOff3tLveGXCEQ0+lj1opUBITTsD82amTW4MO9vucluGYi51g8eZYS4W3uG26M+z+v Ip6LEiWvB0b8EhgcWweeWBXz+3dpygxSJ4BvPHwFu8OwPTYUvuaGOyKSNwnncxQMPCbK zrFJWHSH3pyLZNuqwPv3KToVZkoKmC+3cuh6z17FJXivIm1YjyLmeBVvEuhmz86ym44I yHXw== X-Gm-Message-State: AOAM531yYrqVX/KdmbackQyhRHSsmFiYBO19fFsmu3YKRQbvdib93jRs xAfvLGmMircaYM/bPoQJhdm0IoWOuCiuOA== X-Google-Smtp-Source: ABdhPJytt33yMkpQmfz1N/UddvGUXv+GGlpWA+Ea8+EPw6NjxmfsV8FH9Souz65gtosU16N5ghtOrA== X-Received: by 2002:a37:73c6:: with SMTP id o189mr15214664qkc.216.1604328476898; Mon, 02 Nov 2020 06:47:56 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id q3sm8060371qkf.24.2020.11.02.06.47.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 06:47:56 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: <90DC474F-CC0D-449D-B50D-570121E4D2FE@vigilsec.com> Date: Mon, 2 Nov 2020 09:47:55 -0500 Cc: IETF LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <19C92E29-0A01-4850-84F8-2A836EAF48F6@sn3rd.com> <90DC474F-CC0D-449D-B50D-570121E4D2FE@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 14:48:00 -0000 I looked too and couldn=E2=80=99t find one. spt > On Oct 31, 2020, at 15:46, Russ Housley wrote: >=20 > Sean: >=20 > Are you aware of an OID being assigned for AES-GMAC? I just did a = Google search and did not find one. >=20 > Russ >=20 >=20 >> On Oct 29, 2020, at 5:25 PM, Sean Turner wrote: >>=20 >> I=E2=80=99m no cryptographer, but it seems like we=E2=80=99re moving = away from block encryption algorithms so maybe we should just adopt = AES-GMAC? The caveat here is that I suspect AES-CMAC is just fine as a = MAC algorithm (or somebody will correct me). But, I also feel like = nobody is actually not going to use HMAC-SHA256. Putting that all = together, I guess my order of preference is: >>=20 >> 1. AES-GCM >> 2. drop the SHOULD >> 3. AES-CMAC >>=20 >> spt >>=20 >>> On Oct 25, 2020, at 13:22, Russ Housley = wrote: >>>=20 >>> = https://datatracker.ietf.org/doc/draft-housley-lamps-crmf-update-algs/ >>>=20 >>> In order for the CMP algorithm document to drop SHA-1, this needs to = happen too. I think it is super straightforward. >>>=20 >>> The only real point to discuss in the SHOULD in the MAC algorithm = section. The choices are: >>> - Stick with AES-CMAC, >>> - Pick some other MAC (perhaps AES-GMAC), >>> - Drop the SHOULD altogether. >>>=20 >>> Once this question is resolved, I will ask Tim to make a call for = adoption. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 From nobody Mon Nov 2 07:21:19 2020 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 1A93A3A15B3; Mon, 2 Nov 2020 07:21:09 -0800 (PST) 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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160433046906.22846.13770850635129817305@ietfa.amsl.com> Date: Mon, 02 Nov 2020 07:21:09 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:21:17 -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 : CMP Algorithms Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-algorithms-01.txt Pages : 18 Date : 2020-11-02 Abstract: This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol (CMP). CMP is used to enroll and further manage the lifecycle of X.509 certificates. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-algorithms/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cmp-algorithms-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-algorithms-01 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 Nov 2 07:25:22 2020 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 D39883A0E28; Mon, 2 Nov 2020 07:25:15 -0800 (PST) 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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160433071583.14730.17876324264058960807@ietfa.amsl.com> Date: Mon, 02 Nov 2020 07:25:15 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 15:25:16 -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 : CMP Updates Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-updates-06.txt Pages : 49 Date : 2020-11-02 Abstract: This document contains a set of updates to the base syntax and transport of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210 and RFC 6712. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue, adding new general message types, the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities, and adds an HTTP URI discovery mechanism and extend the URI structure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-updates-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 2 10:42:17 2020 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 532883A05DF; Mon, 2 Nov 2020 10:42:14 -0800 (PST) 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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160434253431.25078.16760796070202783089@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:42:14 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:42:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Lightweight CMP Profile Authors : Hendrik Brockhaus Steffen Fries David von Oheimb Filename : draft-ietf-lamps-lightweight-cmp-profile-04.txt Pages : 81 Date : 2020-11-02 Abstract: The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2, the related Certificate Request Message Format (CRMF) version 2, and the HTTP Transfer for the Certificate Management Protocol. It specifies a subset of CMP and CRMF focusing on typical use cases relevant for managing certificates of devices in many industrial and IoT scenarios. To limit the overhead of certificate management for more constrained devices only the most crucial types of operations are specified as mandatory. To foster interoperability in more complex scenarios, other types of operations are specified as recommended or optional. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-lightweight-cmp-profile-04 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 Nov 2 14:56:33 2020 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 AEF0C3A149B; Mon, 2 Nov 2020 14:56:23 -0800 (PST) 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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160435778366.15418.1748347031702001819@ietfa.amsl.com> Date: Mon, 02 Nov 2020 14:56:23 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-header-protection-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 22:56:31 -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 : Header Protection for S/MIME Authors : Bernie Hoeneisen Daniel Kahn Gillmor Alexey Melnikov Filename : draft-ietf-lamps-header-protection-01.txt Pages : 28 Date : 2020-11-02 Abstract: S/MIME version 3.1 has introduced a feasible standardized option to accomplish Header Protection. However, implementations of Header Protection can cause rendering issues on the receiving side. Clearer specifications regarding message processing, particularly with respect to header sections, are needed in order to resolve these rendering issues. In order to help implementers to correctly compose and render email messages with Header Protection, this document updates S/MIME Header Protection specifications with additional guidance on MIME format, sender and receiver processing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-header-protection-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-header-protection-01 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 Nov 2 15:18:11 2020 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 BA1913A03FC; Mon, 2 Nov 2020 15:18:09 -0800 (PST) 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: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <160435908973.12487.9652123185058158816@ietfa.amsl.com> Date: Mon, 02 Nov 2020 15:18:09 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-header-protection-02.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:18:10 -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 : Header Protection for S/MIME Authors : Bernie Hoeneisen Daniel Kahn Gillmor Alexey Melnikov Filename : draft-ietf-lamps-header-protection-02.txt Pages : 28 Date : 2020-11-02 Abstract: S/MIME version 3.1 has introduced a feasible standardized option to accomplish Header Protection. However, implementations of Header Protection can cause rendering issues on the receiving side. Clearer specifications regarding message processing, particularly with respect to header sections, are needed in order to resolve these rendering issues. In order to help implementers to correctly compose and render email messages with Header Protection, this document updates S/MIME Header Protection specifications with additional guidance on MIME format, sender and receiver processing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-header-protection-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-header-protection-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-header-protection-02 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 Nov 2 15:57:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079A73A161F for ; Mon, 2 Nov 2020 15:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=XNNW42dv; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=tYyJjYUb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVNxer_sWV2G for ; Mon, 2 Nov 2020 15:56:51 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4463A162F for ; Mon, 2 Nov 2020 15:56:05 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604361364; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=wg0PCmUg0wo/o+DVbd8ZTnBAoOr+E2RWRdnB+Rfie6Q=; b=XNNW42dvEAKJNwmfvIsKPZ3XzDaf/uOCzRCE2pzw7CBpTAmOQtmb/uQmxTJ+65F4aBBOX AreMp3WO3H+zfPbBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604361364; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=wg0PCmUg0wo/o+DVbd8ZTnBAoOr+E2RWRdnB+Rfie6Q=; b=tYyJjYUbr4arwuQD3HZJqqxtcIlieX9InAIzZ9gyf245vl9Vni6RHLb7Wjf2mrC9JSr8n 1Ob/ieFmzUENouH4oZSNjcwBoJ4/4zdtaEqzfMCv/fyXPzK/t5sTfVn3WicEPknlOHS7FQu FBTADtYzaOUMdvr9FIQc/u6BagDlrP2kNFTA3G+IT9EBCdYlRIYQ1E8KiOhZb0cPCcE6NDP 8/cxMN0NNLpp4gwdd4a4i9m2J/xNJohNMj3ht8tT4b0Qyj6JQkepNqFZd3nTUH4nnziRTtG NfZTAEXW6sWD/QJ1HVIJPVIim/9mgGAOTDZEhzIvKwaTXypA6Gp96FlpNUzw== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 4914EF9A5 for ; Mon, 2 Nov 2020 18:56:04 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 7DE6020482; Mon, 2 Nov 2020 18:55:59 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 02 Nov 2020 18:55:58 -0500 Message-ID: <87lffjjott.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [lamps] Protected Headers updates: proposed guidance for receiving MUAs to handle two distinct schemes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:57:00 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks-- Bernie and i did some work on trying to get the Protected Headers draft into better shape. I've split out some baseline (not protected-header-specific) guidance for cryptographically-capable MUAs at draft-dkg-lamps-e2e-mail-guidance, which this work relies on. In particular for the protected headers draft, I've written some detailed guidance on *interpreting* protected headers which i think should be useful for any implementer. I don't think any of this guidance should be controversial for an implementer who wants to deal with messages as they're found in the wild. For the receiving side, an implementer probably wants to be able to handle two distinct forms of protected header: the scheme specified in S/MIME 3.1, and the injected headers scheme used by tools like Enigmail, (which I think is marginally friendlier to legacy e-mail clients). My proposed edits describe the two different schemes this way: > This document describes two different structures for how message headers = can be cryptographically protected, and provides guidance for implementers = of MUAs that generate and interpret such messages. > It takes particular care to ensure that messages interact reasonably well= with legacy MUAs. >=20 > ## Two Schemes of Protected Headers=20 >=20 > Unfortunately, there are two different schemes for cryptographically-prot= ected email headers that may be in use on the Internet today. > This document addresses them both and provides guidance to implementers. >=20 > One scheme is the form specified in S/MIME 3.1 and later, which involves = wrapping a `message/rfc822` MIME object with a Cryptographic Envelope. > This document calls this scheme "Wrapped Message", and it is documented i= n more detail in [RFC8551]. > Experience has shown that this form does not interact well with some lega= cy MUAs (see {{wrapped-message-problems}}). >=20 > Consequently, another form of header protection is produced and consumed = by some MUAs, where the protected headers are placed directly on the Crypto= graphic Payload, without using an intervening `message/*` MIME object. > This document calls this scheme "Injected Headers", and it is documented = in more detail in [I-D.autocrypt-lamps-protected-headers]. These two schemes offer equivalent semantics of cryptographic protection for e-mail headers, but they differ in how they interact with legacy clients. The proposed changes then go into some detail about how a receiving MUA should handle protected headers -- regardless of which scheme the incoming message uses. I've attached a draft of that "Receiving Side" here, and welcome feedback on it. The outline of the proposed section rewrite, so you get a feel for it: *. Receiving Side *.1 Identifying that a Message has Protected Headers *.2 Updating the Cryptographic Summary *.3 Rendering a Wrapped Message *.3.1 Example Signed-Only Wrapped Message *.3.2 Example Encrypted-and-Signed Wrapped Message *.4 Rendering a Message with Injected Headers *.4.1 Example Signed-only Message with Injected Headers *.4.2 Example Signed-and-Encrypted Message with Injected Headers *.4.3 Do Not Render Legacy Display Part *.4.3.1 Legacy Display Detection Algorithm *.4.3.2 Legacy Display Example *.5 Affordances for Debugging and Troubleshooting *.6 Composing a Reply to an Encrypted Message with Protected Headers *.6.1 Avoid Leaking Encrypted Headers in Reply *.6.2 Avoid Misdirected Replies to Encrypted Messages with Protected Heade= rs *.7 Implicitly-rendered Header Fields *.8 Unprotected Headers Added in Transit *.8.1 Mailing list headers: List-* and Archived-At As you can see, sections *.3 and *.4 outline the two marginally-different schemes, but all the other guidance is relevant regardless of the scheme received. I'm now working on guidance for *generating* protected headers, but i'm still happy to get criticism and proposed fixes for this interpretation guidance. All the best, --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=receiving-protected-headers.md Content-Transfer-Encoding: quoted-printable ### Receiving Side An MUA that receives a cryptographically-protected e-mail will render it fo= r the user. The receiving MUA will render the message body, a selected subset of header= fields, and (as described in [I-D.dkg-lamps-e2e-mail-guidance]) provide a = summary of the cryptographic properties of the message. Most MUAs only render a subset of header fields by default. For example, few MUAs typically render `Message-Id` or `Received` header fi= elds for the user, but most do render `From`, `To`, `Cc`, `Date`, and `Subj= ect`. A MUA that knows how to handle a message with protected headers makes the f= ollowing two changes to its behavior when rendering a message: =2D If it detects that an incoming message had protected headers, it render= s header fields for the message from the protected headers, ignoring the ex= ternal (unprotected) headers. =2D It includes information in the message's cryptographic summary to indic= ate the types of protection that applied to each rendered header field (if = any). A MUA that handles protected headers does *not* need to render any new head= er fields that it did not render before. #### Identifying that a Message has Protected Headers An incoming message can be identified as having protected headers based on = one of two signals: =2D The Cryptographic Payload has `Content-Type: message/rfc822` or `Conten= t-Type: message/global` and the parameter `forwarded` has a value of `no`. See {{rendering-wrapped-message}} for rendering guidance. =20=20 =2D The Cryptographic Payload has some other `Content-Type` and it has para= meter `protected-headers` set to `v1`. See {{rendering-injected-headers}} for rendering guidance. =20=20 Messages of both types exist in the wild, and a sensible MUA should be able= to handle them both. They provide the same semantics and the same meaning. #### Updating the Cryptographic Summary Regardless of whether a cryptographically-protected message has protected h= eaders, the cryptographic summary of the message should be modified to indi= cate what protections the headers have. Each header individually has exactly one the following protections: =2D `unprotected` (this is the case for all headers in messages that have n= o protected headers) =2D `signed-only` (bound into the same validated signature as the enclosing= message, but also visible in transit) =2D `encrypted-only` (only appears within the cryptographic payload; the co= rresponding external header was either omitted or obfuscated) =2D `encrypted-and-signed` (same as encrypted, but additionally is under a = validatd signature) Note that while the message itself may be `encrypted-and-signed`, some head= ers may be replicated on the outside of the message (e.g. `Date`) Those headers would be `signed-only`, despite the message itself being `enc= rypted-and-signed`. Rendering this information is likely to be complex and messy --- users may = not understand it. It is beyond the scope of this document to suggest any specific graphical a= ffordances or user experience. Future work should include examples of successful rendering of this informa= tion. #### Rendering a Wrapped Message {#rendering-wrapped-message} When the Cryptographic Payload has `Content-Type` of `message/rfc822` or `m= essage/global`, and the parameter `forwarded` is set to `no`, the values of= the protected headers are drawn from the headers of the Cryptographic Payl= oad, and the body that is rendered is the body of the Cryptographic Payload. ##### Example Signed-Only Wrapped Message Consider a message with this structure, where the MUA is able to validate t= he cryptographic signature: ~~~ A =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed-d= ata" =E2=87=A9 (unwraps to) B =E2=94=94=E2=94=AC=E2=95=B4message/rfc822 [Cryptographic Payload] C =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Rendered Body] D =E2=94=9C=E2=94=80=E2=95=B4text/plain E =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ The message body should be rendered the same way as this message: ~~~ C =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative D =E2=94=9C=E2=94=80=E2=95=B4text/plain E =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ It should render header fieldss taken from part `B`. Its cryptographic summary should indicates that the message was signed and = all rendered header fields were included in the signature. The MUA SHOULD ignore header fields from part `A` for the purposes of rende= ring. ##### Example Encrypted-and-Signed Wrapped Message {#example-signed-and-enc= rypted-wrapped} Consider a message with this structure, where the MUA is able to validate t= he cryptographic signature: ~~~ F =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"envelope= d-data" =E2=86=A7 (decrypts to) G =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed-= data" =E2=87=A9 (unwraps to) H =E2=94=94=E2=94=AC=E2=95=B4message/rfc822 [Cryptographic Payload] I =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Rendered Body] J =E2=94=9C=E2=94=80=E2=95=B4text/plain K =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ The message body should be rendered the same way as this message: ~~~ I =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative J =E2=94=9C=E2=94=80=E2=95=B4text/plain K =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ It should render headers taken from part `H`. Its cryptographic summary should indicates that the message was signed and = encrypted. Each rendered header field found in `H` should be compared against the head= er field of the same name from `F`. If the value found in `F` matches the value found in `H`, the header field = should be marked as `signed-only`. If no matching header field was found in `F`, or the value found did not ma= tch the value from `H`, the header field should be marked as `signed-and-en= crypted`. #### Rendering a Message with Injected Headers {#rendering-injected-header= s} When the Cryptographic Payload does not have a `Content-Type` of `message/r= fc822` or `message/global`, and the parameter `protected-headers` is set to= `v1`, the values of the protected headers are drawn from the headers of th= e Cryptographic Payload, and the body that is rendered is the Cryptographic= Payload itself. ##### Example Signed-only Message with Injected Headers ~~~ L =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed-d= ata" =E2=87=A9 (unwraps to) M =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Cryptographic Payload = + Rendered Body] N =E2=94=9C=E2=94=80=E2=95=B4text/plain O =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ The message body should be rendered the same way as this message: ~~~ M =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative N =E2=94=9C=E2=94=80=E2=95=B4text/plain O =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ It should render header fieldss taken from part `M`. Its cryptographic summary should indicates that the message was signed and = all rendered header fields were included in the signature. The MUA SHOULD ignore header fields from part `L` for the purposes of rende= ring. ##### Example Signed-and-Encrypted Message with Injected Headers {#example-= signed-and-encrypted-injected} Consider a message with this structure, where the MUA is able to validate t= he cryptographic signature: ~~~ P =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"envelope= d-data" =E2=86=A7 (decrypts to) Q =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed-= data" =E2=87=A9 (unwraps to) R =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Cryptographic Payload= + Rendered Body] S =E2=94=9C=E2=94=80=E2=95=B4text/plain T =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ The message body should be rendered the same way as this message: ~~~ R =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative S =E2=94=9C=E2=94=80=E2=95=B4text/plain T =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ It should render headers taken from part `R`. Its cryptographic summary should indicates that the message was signed and = encrypted. As in {{example-signed-and-encrypted-wrapped}}, each rendered header field = found in `R` should be compared against the header field of the same name f= rom `P`. If the value found in `P` matches the value found in `R`, the header field = should be marked as `signed-only`. If no matching header field was found in `P`, or the value found did not ma= tch the value from `R`, the header field should be marked as `signed-and-en= crypted`. ##### Do Not Render Legacy Display Part As described [I-D.autocrypt-lamps-protected-headers], a message with crypto= graphic confidentiality protection MAY include a "Legacy Display" part for= backward-compatibility with legacy MUAs The receiving MUA SHOULD avoid rendering the Legacy Display part to the use= r at all, since it is aware of and can render the actual Protected Headers. If a Legacy Display part is detected, it and its enclosing `multipart/mixed= ` wrapper should be discarded before rendering. ###### Legacy Display Detection Algorithm A receiving MUA acting on a message SHOULD detect the presence of a Legacy = Display part and the corresponding "original body" with the following simpl= e algorithm: - Check that all of the following are true for the message: - The Cryptographic Envelope must contain an encrypting Cryptographic Lay= er - The Cryptographic Payload must have a `Content-Type` of `multipart/mixe= d` - The Cryptographic Payload must have exactly two subparts - The first subpart of the Cryptographic Payload must have a `Content-Typ= e` of `text/plain` or `text/rfc822-headers` - The first subpart of the Cryptographic Payload's `Content-Type` must co= ntain a property of `protected-headers`, and its value must be `v1`. - If all of the above are true, then the first subpart is the Legacy Displ= ay part, and the second subpart is the "original body". Otherwise, the mes= sage does not have a Legacy Display part. ###### Legacy Display Example Consider a message with this structure, where the MUA is able to validate t= he cryptographic signature: ~~~ U =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"envelope= d-data" =E2=86=A7 (decrypts to) V =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed-= data" =E2=87=A9 (unwraps to) W =E2=94=94=E2=94=AC=E2=95=B4multipart/mixed [Cryptographic Payload] X =E2=94=9C=E2=94=80=E2=95=B4text/plain [Legacy Display] Y =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Rendered Body] Z =E2=94=9C=E2=94=80=E2=95=B4text/plain A' =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ The message body should be rendered the same way as this message, effective= ly hiding the Legacy Display part (`X`) and its wrapper: ~~~ Y =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative Z =E2=94=9C=E2=94=80=E2=95=B4text/plain A' =E2=94=94=E2=94=80=E2=95=B4text/html ~~~ It should render headers taken from part `W`, following the same guidance a= s in {{example-signed-and-encrypted-injected}} and {{example-signed-and-enc= rypted-wrapped}} about the cryptographic status of each rendered header fie= ld. #### Affordances for Debugging and Troubleshooting {#debugging-and-troubles= hooting} Note that advanced users of an MUA may need access to the original message,= for example to troubleshoot problems with the MUA itself, or problems with= the SMTP transport path taken by the message. A MUA that applies these rendering guidelines SHOULD ensure that the full o= riginal source of the message as it was received remains available to such = a user for debugging and troubleshooting. #### Composing a Reply to an Encrypted Message with Protected Headers When composing a reply to an encrypted message with protected headers, the = MUA is acting both as a receiving MUA and as a sending MUA. Special guidance applies here, as things can go wrong in at least two ways:= leaking previously-confidential information, and replying to the wrong par= ty. ##### Avoid Leaking Encrypted Headers in Reply As noted in [I-D.dkg-lamps-e2e-mail-guidance], an MUA in this position MUST= NOT leak previously-encrypted content in the clear in a followup message. The same is true for protected headers. Values from any header field that was identified as either `encrypted` or `= signed-and-encrypted` based on the steps outlined above MUST NOT be placed = in cleartext output when generating a message. In particular, if `Subject` was encrypted, and it is copied into the draft = encrypted reply, the replying MUA MUST obfuscate the `Subject` field in the= cleartext header as described above. ##### Avoid Misdirected Replies to Encrypted Messages with Protected Header= s {#avoid-misdirected-replies} When replying to a message, the Composing MUA typically decides who to send= the reply to based on: =2D the `Reply-To`, `Mail-Followup-To`, or `From` headers =2D optionally, the other `To` or `Cc` headers (if the user chose to "reply= all") When a message has protected headers, the replying MUA MUST populate the de= stination fields of the draft message using the protected headers, and igno= re any unprotected headers. This mitigates against an attack where Mallory gets a copy of an encrypted = message from Alice to Bob, and then replays the message to Bob with an addi= tional `Cc` to Mallory's own e-mail address in the message's outer header. If Bob knows Mallory's certificate already, and he replies to such a messag= e without following the guidance in this section, it's likely that his MUA = will encrypt the cleartext of the message directly to Mallory. #### Implicitly-rendered Header Fields While `From` and `To` and `Cc` and `Subject` and `Date` are often explicitl= y rendered to the user, some header fields do affect message display, witho= ut being explicitly rendered. For example, `Message-Id`, `References`, and `In-Reply-To` header fields ma= y collectively be used to place a message in a "thread" or series of messag= es. In another example, {{avoid-misdirected-replies}} observes that the value o= f the `Reply-To` field can influence the draft reply message. So while the user may never see the `Reply-To` header directly, it is impli= citly "rendered" when the user interacts with the message by replying to it. An MUA that depends on any implicitly-rendered header field in a message wi= th protected headers SHOULD use the value from the protected header, and SH= OULD NOT use any value found outside the cryptographic protection. #### Unprotected Headers Added in Transit Some headers are legitimately added in transit, and could not have been kno= wn to the sender at message composition time. The most common of these headers are `Received` and `DKIM-Signature`, neith= er of which are typically rendered, either explicitly or implicitly. If a receiving MUA has specific knowledge about a given header field, inclu= ding that: =2D the header field would not have been known to the original sender, and =2D the header field might be rendered explicitly or implicitly, then the MUA MAY decide to operate on the value of that header field from t= he unprotected header section, even though the message has protected header= s. The MUA MAY prefer to verify that the headers in question have additional t= ransit-derived cryptographic protections (e.g., to test whether they are co= vered by a valid `DKIM-Signature`) before rendering or acting on them. Specific examples appear below. ##### Mailing list headers: List-* and Archived-At If the message arrives through a mailing list, the list manager itself may = inject headers (most of which start with `List-`) in the message: =2D `List-Archive` =2D `List-Subscribe` =2D `List-Unsubscribe` =2D `List-Id` =2D `List-Help` =2D `List-Post` =2D `Archived-At` For some MUAs, these headers are implicitly rendered, by providing buttons = for actions like "Subscribe", "View Archived Version", "Reply List", "List = Info", etc. An MUA that receives a message with protected headers that contains these h= eader fields in the unprotected section, and that has reason to believe the= message is coming through a mailing list MAY decide to render them to the = user (explicitly or implicitly) even though they are not protected. FIXME: other examples of unprotected transit headers? --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6CcjwAKCRDEDyVUMvKB D5EPAP0W1syBrZjXQeIAwKcLnoJoe8m2RwB+DSpGmdb9VY7WkgEA29Ds5Bi+C2DT T3UESI+bEBzv6ua09xXuPKRCkQCcJwg= =6/ZW -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Nov 3 17:32:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E83A0DCC for ; Tue, 3 Nov 2020 17:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=vJndPmhQ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=jmh5hi4N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMy9zjecHR0u for ; Tue, 3 Nov 2020 17:32:02 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1E53A097E for ; Tue, 3 Nov 2020 17:32:01 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604453520; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tmPEW+OvbIwIDC5fq36f020Ne0l7f2qpwYQ//9cL804=; b=vJndPmhQSDicm6Qp2qTAvh9TgdHHA7agMkeVyueFfczqFSwGP4ear9SfH+zvBKr4atJVB FewvKVLnRtVcPLNDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604453520; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=tmPEW+OvbIwIDC5fq36f020Ne0l7f2qpwYQ//9cL804=; b=jmh5hi4NvdoqYVivDrm3oCbmN9AQtT1f4UGojc1dd8SRN8qQzYXA7YT1Lp/eV/XutVaw8 atMNC9nQIoXPcrTxV9fk+Hqu9iI1DYOxzMcyeigh8GqCq85DYZguv4ZLbWUJ38ijLom14Zl eSz/hSGmMWQZRkp1XHKFQ41HoGZthf7Gf6qX2zXsS6X9A1eBFZ9vkK0+u901rfrSSTD7ecQ YVphnDydpr+b43fck07ZZI1G66bWOSDFQKlhxC0aAD55bssZEaJugpK+CWZebLmmqORg+ir QG2GlJjjt3N4gpWbD5Ib2J+jftYz0zid0Cui8BdzWXwLqDpRc5Y7K57AEGbQ== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 106F4F9A5 for ; Tue, 3 Nov 2020 20:31:59 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0274F20374; Tue, 3 Nov 2020 20:31:47 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG In-Reply-To: <87lffjjott.fsf@fifthhorseman.net> References: <87lffjjott.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 03 Nov 2020 20:31:47 -0500 Message-ID: <875z6lkiv0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Protected Headers updates: proposed guidance for receiving MUAs to handle two distinct schemes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 01:32:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hey all-- Re-reading the work i sent earlier, i noticed a small but important mistake. In particular, i'd misidentified the MIME part where the protected headers live in "Wrapped Message"-style header protections: On Mon 2020-11-02 18:55:58 -0500, Daniel Kahn Gillmor wrote: > ##### Example Signed-Only Wrapped Message > > Consider a message with this structure, where the MUA is able to validate= the cryptographic signature: > > ~~~ > A =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signed= -data" > =E2=87=A9 (unwraps to) > B =E2=94=94=E2=94=AC=E2=95=B4message/rfc822 [Cryptographic Payload] > C =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Rendered Body] > D =E2=94=9C=E2=94=80=E2=95=B4text/plain > E =E2=94=94=E2=94=80=E2=95=B4text/html > ~~~ > > The message body should be rendered the same way as this message: > > ~~~ > C =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative > D =E2=94=9C=E2=94=80=E2=95=B4text/plain > E =E2=94=94=E2=94=80=E2=95=B4text/html > ~~~ > > It should render header fields taken from part `B`. In fact, the rendered header fields should be taken from part `C`. > ##### Example Encrypted-and-Signed Wrapped Message {#example-signed-and-e= ncrypted-wrapped} > > Consider a message with this structure, where the MUA is able to validate= the cryptographic signature: > > ~~~ > F =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"envelo= ped-data" > =E2=86=A7 (decrypts to) > G =E2=94=94=E2=94=80=E2=95=B4application/pkcs7-mime; smime-type=3D"signe= d-data" > =E2=87=A9 (unwraps to) > H =E2=94=94=E2=94=AC=E2=95=B4message/rfc822 [Cryptographic Payload] > I =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative [Rendered Body] > J =E2=94=9C=E2=94=80=E2=95=B4text/plain > K =E2=94=94=E2=94=80=E2=95=B4text/html > ~~~ > > The message body should be rendered the same way as this message: > > ~~~ > I =E2=94=94=E2=94=AC=E2=95=B4multipart/alternative > J =E2=94=9C=E2=94=80=E2=95=B4text/plain > K =E2=94=94=E2=94=80=E2=95=B4text/html > ~~~ > > It should render headers taken from part `H`. Similarly, here, the rendered headers shold b taken from part `I`, not `H`. And the text in the following lines should also replace `H` with `I`: > Its cryptographic summary should indicates that the message was signed an= d encrypted. > Each rendered header field found in `H` should be compared against the he= ader field of the same name from `F`. > If the value found in `F` matches the value found in `H`, the header fiel= d should be marked as `signed-only`. > If no matching header field was found in `F`, or the value found did not = match the value from `H`, the header field should be marked as `signed-and-= encrypted`. I've fixed this in the version in revision control. I'd appreciate any other review of the text! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6IEgwAKCRDEDyVUMvKB D65FAQCa6EG0DVlvwBRCiRChfQQl9zXhdbzE/4kfXc0xJW4EoQEA8kMTCirNN5SS i9cYLzckM5Y1/3JW+mRlZp/QO5/mLAs= =UoxJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 05:40:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833873A1250 for ; Wed, 4 Nov 2020 05:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLBLIvJxzhAB for ; Wed, 4 Nov 2020 05:40:01 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 1D72F3A1251 for ; Wed, 4 Nov 2020 05:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604497190; d=isode.com; s=june2016; i=@isode.com; bh=s1ZL2pWFb1K8oytds16SRSbGxJas5dODfAUpLdsjqG8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kiickm3Jhq/U+NQQjotSnN3JEYSDEEEmezZPX/7OYnfnqgQ9hlOfAoUHJKJZa/97luFZCd yefd0FeqBYGX+lyhe17RWx2fgBU2WbnhbQdptxiGr0bE1DLA14R0bgUm2WJfsr3ZyCkVLh JoWPfsMm+TAlXpG1Az/pqtYT4WFGzsM=; Received: from [172.27.252.25] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2020 13:39:50 +0000 To: Daniel Kahn Gillmor , LAMPS WG References: <87lffjjott.fsf@fifthhorseman.net> <875z6lkiv0.fsf@fifthhorseman.net> From: Alexey Melnikov Message-ID: Date: Wed, 4 Nov 2020 13:39:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <875z6lkiv0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] Protected Headers updates: proposed guidance for receiving MUAs to handle two distinct schemes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 13:40:04 -0000 Hi DKG, On 04/11/2020 01:31, Daniel Kahn Gillmor wrote: > I've fixed this in the version in revision control. I'd appreciate any > other review of the text! After your fixes the text looks good to me! Best Regards, Alexey From nobody Wed Nov 4 06:08:41 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838303A0A73 for ; Wed, 4 Nov 2020 06:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=W9bGqQOG; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=SZDUV3Lx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yu0ywNSEvme for ; Wed, 4 Nov 2020 06:08:39 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E343A0A6A for ; Wed, 4 Nov 2020 06:08:38 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604498916; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=x2/U+/T/oVsLmcv6xrLpdSg7+TuR1Yju0ScP422K8zA=; b=W9bGqQOGZ5su9cAOiO6ECB6QiKb+rmyEtT0dgIPpBX+73BCc+T0EnKikQ6ks9RNmiB/Q7 qgEyOvcpMM8ku4pDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604498916; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=x2/U+/T/oVsLmcv6xrLpdSg7+TuR1Yju0ScP422K8zA=; b=SZDUV3LxUiPD2eNaLve8N71ipgmq1UzKsHV0PIlb/p1oqGx8jWaXKz8rA4UDI5BD3+oMb YhBuf4tSyCIhEy/dCkwrWLQrWX6p91hMFZ02Q8QcUysMulvotPahoiZ0GFu0PyaPdAsbSvW PUt+J1WRnhizx38j6LsjmvNVgho6RCRq4M9XyEECRWKX6DbS1QsOvKxDM8Qx977heXsTPh6 mOx833cZTK5Q6w2TjRDL6QoDuQgyQcMguqNe7YKgCXjJSFSpUFPSyDYhIBxQ2oOT6F0cH6f xkxO8f5ieBr6yj67DguuG2ypHIWteQxo88qHEcqiqVqF/htUjh+L8OrDR0AQ== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id E5EBCF9A5 for ; Wed, 4 Nov 2020 09:08:36 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id DF836203CE; Wed, 4 Nov 2020 09:08:31 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 04 Nov 2020 09:08:29 -0500 Message-ID: <87361pjjtu.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 14:08:41 -0000 --=-=-= Content-Type: text/plain Hi LAMPS folks-- As I'm working on the header protection draft, I find it would be useful to have well-known key and certificate material that can be used for the test vectors. In related past work, I've used the S/MIME certificates and keys (and certificate authority) that I published last year in draft-dkg-lamps-samples: https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/ This draft is now expired, but the data contained in there is still useful. It consists of certificate and secret key material for three parties: a certificate authority, and two correspondents: Alice and Bob. The sample certificates for Alice and Bob are both issued by the sample certificate authority. I don't think there's anything objectionable or complicated in the document, and the contents should be easy for people to test. This does not fall into one of the three numbered bullets in the LAMPS charter, but it's certainly relevant to LAMPS as it touches on both S/MIME (the certificates are intended for e-mail use) and X.509. I'd like to produce a permanent, WG-reviewed reference for this material, which i think means WG adoption. Alternately, i can pursue the independent-stream, but i would much rather have WG eyes on it. I could take this through SECDISPATCH, but i'm sure it would be routed here. So, I'm asking for WG adoption of this document. If the chairs think we'd need a charter revision to adopt it, I propose adding the following paragraph to the charter: 4. Publication of sample keys and certificates for use with S/MIME. Having stable, well-known keys and certificates for use in generating test vectors will facilitate testing and interoperability among S/MIME-enabled e-mail implementations. I'm happy to cede authority on the document to the WG consensus. I volunteer to continue as editor of the document in this case, but i'd also be happy if someone else wanted to edit it. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6K13wAKCRDEDyVUMvKB D3ZkAQDnsWBRGDrDdlW5XXERGHcPrPSxJw4LC1TtLkDBOlksrgEAkeBGsykzjqKn qx6Auq4s/2G69PXKHgXGN0P+4Ia8iA4= =8GgP -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 08:31:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505FF3A0D45 for ; Wed, 4 Nov 2020 08:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI_Kx3jvYKM2 for ; Wed, 4 Nov 2020 08:31:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10BB3A097A for ; Wed, 4 Nov 2020 08:31:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A90CB38A56; Wed, 4 Nov 2020 11:31:22 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Hrh8r37VV9IF; Wed, 4 Nov 2020 11:31:20 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 932B538A54; Wed, 4 Nov 2020 11:31:20 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C0D405DF; Wed, 4 Nov 2020 11:31:16 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor , LAMPS WG In-Reply-To: <87361pjjtu.fsf@fifthhorseman.net> References: <87361pjjtu.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 16:31:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > In related past work, I've used the S/MIME certificates and keys (and > certificate authority) that I published last year in > draft-dkg-lamps-samples: > https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/ > This draft is now expired, but the data contained in there is still > useful. It consists of certificate and secret key material for three > parties: a certificate authority, and two correspondents: Alice and B= ob. > The sample certificates for Alice and Bob are both issued by the samp= le > certificate authority. > I don't think there's anything objectionable or complicated in the > document, and the contents should be easy for people to test. > This does not fall into one of the three numbered bullets in the LAMPS > charter, but it's certainly relevant to LAMPS as it touches on both > S/MIME (the certificates are intended for e-mail use) and X.509. > I'd like to produce a permanent, WG-reviewed reference for this > material, which i think means WG adoption. Alternately, i can pursue > the independent-stream, but i would much rather have WG eyes on it. I think that it's very very useful to have test vectors here. They need to be renewed regularly as algorithms and key sizes changes. Old ones are even valuable because they are expired. > I could take this through SECDISPATCH, but i'm sure it would be routed > here. > So, I'm asking for WG adoption of this document. If the chairs think > we'd need a charter revision to adopt it, I propose adding the follow= ing > paragraph to the charter: I think that the WG should adopt it, and I don't think that we need a charter revision to do so. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+i11QACgkQgItw+93Q 3WWp2gf+JmxDLt4Mvdy3xL5PDsWcv02OZeswVA6Zb7DbeODeJ+L2M5qH5sN0FDdh DK8f+4Iki+P9WWc3lnFcIEYDRFSwhSJk1LIf499lnh1HawB6Tmi5/v5yTT7J+ZTB X9mLC4eOE7UUMcFdw2hpYHpHeCg7clDzWqwp4br/EBSx1Jfm83XMi07fyBLI1XxU NUqSIIX25rKRAIess6czlt3RQ2VewCw87fSThrq0zIDt3KvcDyE0GAL5TX2kNc+Q +DrREKFDRv2SIbj2bdUjdT0yxoRPE/cQI9L2beFFABKKLOrgKkxTpNH90rswGARf XndARmwtyh1qgNAj6dWsWuGh2IeYvA== =u4Hq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 08:38:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A9F3A0D42 for ; Wed, 4 Nov 2020 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMAEzkN-FT3C for ; Wed, 4 Nov 2020 08:38:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F653A1311 for ; Wed, 4 Nov 2020 08:38:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 89B7438A58; Wed, 4 Nov 2020 11:38:19 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ejffHLztDtaP; Wed, 4 Nov 2020 11:38:18 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B57F38A57; Wed, 4 Nov 2020 11:38:18 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EC3165DF; Wed, 4 Nov 2020 11:38:14 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor cc: LAMPS WG In-Reply-To: <87361pjjtu.fsf@fifthhorseman.net> References: <87361pjjtu.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 16:38:19 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > As I'm working on the header protection draft, I find it would be use= ful > to have well-known key and certificate material that can be used for = the > test vectors. > In related past work, I've used the S/MIME certificates and keys (and > certificate authority) that I published last year in > draft-dkg-lamps-samples: > https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/ As an editorial nit, the various samples need to have , etc. and a file XXX so that they can be extracted easily. I also suggest you leave the --text output from openssl's x509 processor with the certificate for human consumption. Finally, https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki.git and https://github.com/rgmhtt/draft-moskowitz-eddsa-pki.git is somewhat related, and perhaps we should consider merging of efforts, or producing one with the other. Bob, Henk and I never expected these to be published, but it might be worth making your samples draft be a generated output. I modularized the first one so that it could be re-run more easily, but haven't touched the second one yet. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+i2PYACgkQgItw+93Q 3WUYHAf/bsOvBF568c+2aHQIkcIOvx5xNwGiHc+7JmVRuB6WtXaqVZxabPRMlwy7 VneIvS0ohawqhY+Gnt7QPk1DCjSqC0HGH+qN2YOIFUx8N7N0Qr9J9eG9KpkWk7R3 i8OmwJEOxL3xpRxivVoN9EXpSd3HSSb9s7yJOKxVa8iNIoaMvcjgdlOZERv1LG1X PjZ+Axd3U1ybw7CVmW8uk2KbgTc5GUKralW5M/JlWBjeU933CUmxI9vYxoPyLz6o ew5Q+tvcurWCc1s3UFJ1D0tBmLbTKbXy5DnbwSmUqo4VaA1W5LhCu66An5wGc29F Jkv8k3iyEA0oomLzG8K9nuJmrQse/g== =+1Iu -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 08:50:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9693C3A1342 for ; Wed, 4 Nov 2020 08:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljajZsrYF_bX for ; Wed, 4 Nov 2020 08:50:54 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id D688B3A0D70 for ; Wed, 4 Nov 2020 08:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604508652; d=isode.com; s=june2016; i=@isode.com; bh=cWBcmui3SzhIHSXEZBMv5iaIwRvlVXgx8i+5b+kOhXg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=JdlGFsB36dzaGhUcymUbei8DTYEb1MjiPJJr0GRr4zYRRSYC29/ml54kR4M3+Lnu1l482f Z6Y67XSbafZkJ3mmXXuMqiSYSkgLyWTC2e+COC9yw5uCaxeDb5wuw4I6i7iMdMb2RaMiGo d+dsQX1wR8cKS8hHhn/tPJQeP998dzg=; Received: from [172.27.252.42] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2020 16:50:52 +0000 To: Daniel Kahn Gillmor , LAMPS WG References: <87361pjjtu.fsf@fifthhorseman.net> From: Alexey Melnikov Message-ID: <5c488acf-2a18-f2e1-1f77-0c768f388dd4@isode.com> Date: Wed, 4 Nov 2020 16:50:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <87361pjjtu.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 16:50:56 -0000 Hi, On 04/11/2020 14:08, Daniel Kahn Gillmor wrote: > Hi LAMPS folks-- > > As I'm working on the header protection draft, I find it would be useful > to have well-known key and certificate material that can be used for the > test vectors. > > In related past work, I've used the S/MIME certificates and keys (and > certificate authority) that I published last year in > draft-dkg-lamps-samples: > > https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/ > > This draft is now expired, but the data contained in there is still > useful. It consists of certificate and secret key material for three > parties: a certificate authority, and two correspondents: Alice and Bob. > The sample certificates for Alice and Bob are both issued by the sample > certificate authority. > > I don't think there's anything objectionable or complicated in the > document, and the contents should be easy for people to test. > > This does not fall into one of the three numbered bullets in the LAMPS > charter, but it's certainly relevant to LAMPS as it touches on both > S/MIME (the certificates are intended for e-mail use) and X.509. > > I'd like to produce a permanent, WG-reviewed reference for this > material, which i think means WG adoption. Alternately, i can pursue > the independent-stream, but i would much rather have WG eyes on it. > > I could take this through SECDISPATCH, but i'm sure it would be routed > here. > > So, I'm asking for WG adoption of this document. If the chairs think > we'd need a charter revision to adopt it, I propose adding the following > paragraph to the charter: > > 4. Publication of sample keys and certificates for use with > S/MIME. Having stable, well-known keys and certificates for use > in generating test vectors will facilitate testing and > interoperability among S/MIME-enabled e-mail implementations. > > I'm happy to cede authority on the document to the WG consensus. I > volunteer to continue as editor of the document in this case, but i'd > also be happy if someone else wanted to edit it. I agree this document should be adopted by the WG. I am not yet sure that the document ever need to become an RFC (as opposed to just staying as a draft that gets refreshed periodically), but I can probably be convinced. Best Regards, Alexey From nobody Wed Nov 4 10:04:43 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F103A0E47 for ; Wed, 4 Nov 2020 10:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOGBUb4eCfFR for ; Wed, 4 Nov 2020 10:04:40 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4E03A0DEE for ; Wed, 4 Nov 2020 10:04:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A41C4300B22 for ; Wed, 4 Nov 2020 13:04:37 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lmfXUCglws9s for ; Wed, 4 Nov 2020 13:04:36 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id DE822300B78; Wed, 4 Nov 2020 13:04:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <87361pjjtu.fsf@fifthhorseman.net> Date: Wed, 4 Nov 2020 13:04:37 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <433E58C8-F027-4F4F-89FF-A97FA0E8D063@vigilsec.com> References: <87361pjjtu.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:04:42 -0000 DKG: My view is that the document would be very useful if the conclusions = from the experiment were at the front of the document, and then the = details of the experiment follow. In the past, the S/MIME WG published RFC 4134, which helped foster = interoperability. Your I-D had a different intent, at least originally. = So, a restructuring now that the header-protection standards are used = would be another possibility. Russ > On Nov 4, 2020, at 9:08 AM, Daniel Kahn Gillmor = wrote: >=20 > Hi LAMPS folks-- >=20 > As I'm working on the header protection draft, I find it would be = useful > to have well-known key and certificate material that can be used for = the > test vectors. >=20 > In related past work, I've used the S/MIME certificates and keys (and > certificate authority) that I published last year in > draft-dkg-lamps-samples: >=20 > https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/ >=20 > This draft is now expired, but the data contained in there is still > useful. It consists of certificate and secret key material for three > parties: a certificate authority, and two correspondents: Alice and = Bob. > The sample certificates for Alice and Bob are both issued by the = sample > certificate authority. >=20 > I don't think there's anything objectionable or complicated in the > document, and the contents should be easy for people to test. >=20 > This does not fall into one of the three numbered bullets in the LAMPS > charter, but it's certainly relevant to LAMPS as it touches on both > S/MIME (the certificates are intended for e-mail use) and X.509. >=20 > I'd like to produce a permanent, WG-reviewed reference for this > material, which i think means WG adoption. Alternately, i can pursue > the independent-stream, but i would much rather have WG eyes on it. >=20 > I could take this through SECDISPATCH, but i'm sure it would be routed > here. >=20 > So, I'm asking for WG adoption of this document. If the chairs think > we'd need a charter revision to adopt it, I propose adding the = following > paragraph to the charter: >=20 > 4. Publication of sample keys and certificates for use with > S/MIME. Having stable, well-known keys and certificates for use > in generating test vectors will facilitate testing and > interoperability among S/MIME-enabled e-mail implementations. >=20 > I'm happy to cede authority on the document to the WG consensus. I > volunteer to continue as editor of the document in this case, but i'd > also be happy if someone else wanted to edit it. >=20 > --dkg From nobody Wed Nov 4 10:36:49 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F023A15FB for ; Wed, 4 Nov 2020 10:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=E/UIkkyj; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=BIYr+Uvg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zx12NSQNcvJQ for ; Wed, 4 Nov 2020 10:36:45 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECD63A15F2 for ; Wed, 4 Nov 2020 10:36:45 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604515004; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=QBjjiOUHLsWilF+ChFMBJKa01sC/IK+SDwRgmhqbXu0=; b=E/UIkkyjpikER9X+9yg52tZ5KKCGxesk8DyFzEqMC4otmtKU8N+LYemb5u2C5PI8o+V+3 qx97ig6UxDMq7c1Dw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604515004; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=QBjjiOUHLsWilF+ChFMBJKa01sC/IK+SDwRgmhqbXu0=; b=BIYr+UvgxbntjNbAhZOIlv/JERPfs87OWqaHe61sGELAm7d9FK302BYdryJC4XCDJ5xMJ N2uDW+kep2DMlJ0Idb4pr7sHH03IjnUQiHUPyKUXrqNLVyD1l+qbSKBEnSqg/VTY7w08gns XxwUsNf6/AkZ5Doqvf/Nr5JYipvr2VjTEBaInAUEg7elxZgo3gWo4rwZ/UAkCIHQt8fcm0R YHaG9E1LM3VJrE59HBZGLMyrkZrktgaZqFlB1kJsW7377fGsysoNZUX+Z6IzBxEkozybmon hiDiw/3gRgv98EsfssmqemQCP3ONr6FBGME+uVgw+Wag0AjSgqFZ03Ip6SSQ== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 79916F9A5; Wed, 4 Nov 2020 13:36:44 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 77C58203CE; Wed, 4 Nov 2020 13:00:38 -0500 (EST) From: Daniel Kahn Gillmor To: Alexey Melnikov , LAMPS WG In-Reply-To: <5c488acf-2a18-f2e1-1f77-0c768f388dd4@isode.com> References: <87361pjjtu.fsf@fifthhorseman.net> <5c488acf-2a18-f2e1-1f77-0c768f388dd4@isode.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 04 Nov 2020 13:00:36 -0500 Message-ID: <87zh3xhuij.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:36:48 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2020-11-04 16:50:33 +0000, Alexey Melnikov wrote: > I agree this document should be adopted by the WG. Thanks for the support! > I am not yet sure that the document ever need to become an RFC (as=20 > opposed to just staying as a draft that gets refreshed periodically),=20 > but I can probably be convinced. The main reason is that i want it to be referencable (and not expired) by other drafts that have test vectors. I note that if we're changing the certificates in question regularly, that will break any test vector that relies on it. So static/permanent seems simple and advantagous, and (afaict) in the IETF static/permanent means RFC. Otherwise, i don't really care whether it's an RFC or not. If you think that the WG can maintain the document in draft state perpetually, that'd be fine with me, but i don't understand the administrative process for ensuring that happens. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6LsRgAKCRDEDyVUMvKB D+NOAP9bUXkCLul0eYsWb+Fmn6Vo3l+gMV49BiK5nEkbH6vRawEAwINrmOs2jgAm 2fMq/myToSiVonpjqZSIcWnmtVelUAE= =GfR2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 10:36:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC03A15F2 for ; Wed, 4 Nov 2020 10:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Ct6hqnkG; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=WTyslIIa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5NXVEyPO5yK for ; Wed, 4 Nov 2020 10:36:46 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447AA3A15FA for ; Wed, 4 Nov 2020 10:36:46 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604515005; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=F97rdOYzowAanzQJTXB4cU4TumfcxiXsVDwBpBTPm4g=; b=Ct6hqnkG1tByFhzcU9g5rCHbIxucwP6bjHj0A8ArmmlpDnFI/2Bo/IEEToqTLjS9pa/+g EMjp23jn6/AAOaHDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604515005; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=F97rdOYzowAanzQJTXB4cU4TumfcxiXsVDwBpBTPm4g=; b=WTyslIIa6qb3VC3xjL0mrBTiES8j09PeHYplxQPnvQtCy0nZeBiWETp065fC6UIe9ssAy c1yiBUnpO9BSj8nZKlhfh4iK1SWngWlI4tTQZCPpsY5DC8B+vJtVMha0cvDbOa+N7Slp4f8 kTunX1mgW3vzXxqYvFrNaCFN0JSAKW4W6sFhOnczTMa5SiFz+uYQYIvNwzswYVBOakmYdwW QqKfyT8Ap0jL7nOYOLNEYcUpM1C637aO8x7dom01f5xKKXs2X2qkIDrc4ogvdvZ/diHq38l NGJnx3IF8EvRL1i9GwMh9lRYccYAqZ6BmVjGPEa5zvxJhJbkTOuKUYJlrxlg== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 0C264F9A6; Wed, 4 Nov 2020 13:36:45 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 162E420485; Wed, 4 Nov 2020 13:36:33 -0500 (EST) From: Daniel Kahn Gillmor To: Michael Richardson , LAMPS WG In-Reply-To: <8465.1604507476@localhost> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 04 Nov 2020 13:36:30 -0500 Message-ID: <87v9elhsup.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:36:49 -0000 --=-=-= Content-Type: text/plain On Wed 2020-11-04 11:31:16 -0500, Michael Richardson wrote: > I think that it's very very useful to have test vectors here. > They need to be renewed regularly as algorithms and key sizes changes. > Old ones are even valuable because they are expired. The draft currently uses 2048-bit RSA keys, bound into certificates that expire in ~2050. My original intent was to *not* have the certificates expire in the near future. I want to encourage the creation of test vectors that are supposed to be technically valid for a decade or two at least. (of course no test vectors produced with this material are *really* valid, because the secret key material is published and known) If we want deliberately expired certificates, i think we should generate them such that they are already expired, so that people can produce deliberately expired test vectors. I'd be willing to consider adding such a thing to the draft if the WG feels strongly that it's needed, but i started the draft with the intent of keeping it simple, focusing on how valid certs are expected to look in the S/MIME context. Note: i am a big fan of negative examples in test suites generally, but a catalog of all the ways that a certificate might *not* be valid in a given context is a huge undertaking, much larger than the current draft. It's not just simple certificate expiration. A catalog of negative examples -- just for S/MIME purposes -- should include the following issues in all different certificates (root CA and end entity of course, but also intermediate certs, which the current draft doesn't touch on): - expired certs - certs "from the future" - insufficient keyUsage or extendedKeyUsage flags - weak key material - bad digest algorithms in the signature - critical unknown ("poison") extensions - probably a lot more! This seems like it would be a different (and much bigger) project than the current draft, so i'm wary of the bloat. > I think that the WG should adopt it, and I don't think that we need a > charter revision to do so. Thanks for the statement of support. > As an editorial nit, the various samples need to have , > etc. and a file XXX so that they can be extracted easily. Interesting! the draft uses a markdown-to-xml workflow (see the Makefile in https://gitlab.com/dkg/lamps-samples) and i don't know how to make that workflow generate or filenames. If anyone has pointers to how to make that work, i'd welcome suggestions (merge requests directly on gitlab would be bonus). > I also suggest you leave the --text output from openssl's x509 > processor with the certificate for human consumption. I'm not convinced that we want to embed the output of whatever particular version of OpenSSL i happen to have on my computer today into the draft itself. People can use their preferred X.509 renderer on the cert as given if they want to review it in more detail. The goal of the draft is to describe the salient features in human terms, and provide an object that any tool can be run against. [ The certificates were originally generated with certtool from GnuTLS (again, see the Makefile), not OpenSSL, not that it matters ] > Finally, https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki.git > and https://github.com/rgmhtt/draft-moskowitz-eddsa-pki.git > is somewhat related, and perhaps we should consider merging of efforts, or > producing one with the other. I'd be happy to include additional certificates using ECDSA and EDDSA in a future revision of this draft. However, I don't think that guidance about operating a PKI, or suggestions about how to use `openssl` from the command line belong in this draft. I'd welcome Bob's (or anyone's) help in making sure that the modern cryptographic algorithms are represented in a catalog of sample certificates. Out of curiosity: how is one expected to encrypt an e-mail message to an ECDSA or EDDSA S/MIME certificate? Or are those expected to be signing-only certificates? > Bob, Henk and I never expected these to be published, but it might be > worth making your samples draft be a generated output. The samples draft is already a generated output -- see the Makefile in the gitlab repo. I've also committed the generated material so that the entropy involved in the key generation (picking large primes) and certificate creation (datestamps and serial number) doesn't cause unnecessary churn in the draft, but if there are problems with any of the sample certificates, it should be pretty straightforward to tweak the generation steps, destroy the artifacts, and have them be recreated. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6L0sAAKCRDEDyVUMvKB D2vbAQCqzcK4N3sQ4ENK5igfMauJKX3VPLufdljYUuUQHVkbWAD+PqOmOiPqGlCj VG27w3byMV/0eDli+Icug0AleVybeQs= =LE6k -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 11:03:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA693A0F2F for ; Wed, 4 Nov 2020 11:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsluFS3310QZ for ; Wed, 4 Nov 2020 11:03:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79D83A0F22 for ; Wed, 4 Nov 2020 11:03:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C9E6F38AA0; Wed, 4 Nov 2020 14:03:47 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B7gXZm6EvLr3; Wed, 4 Nov 2020 14:03:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6350238A9F; Wed, 4 Nov 2020 14:03:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 87E9B26; Wed, 4 Nov 2020 14:03:43 -0500 (EST) From: Michael Richardson To: Alexey Melnikov , Daniel Kahn Gillmor , LAMPS WG In-Reply-To: <5c488acf-2a18-f2e1-1f77-0c768f388dd4@isode.com> References: <87361pjjtu.fsf@fifthhorseman.net> <5c488acf-2a18-f2e1-1f77-0c768f388dd4@isode.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:03:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alexey Melnikov wrote: >> I'm happy to cede authority on the document to the WG consensus. I >> volunteer to continue as editor of the document in this case, but i'd >> also be happy if someone else wanted to edit it. > I agree this document should be adopted by the WG. > I am not yet sure that the document ever need to become an RFC (as > opposed to just staying as a draft that gets refreshed periodically), > but I can probably be convinced. I guess any references to it from other documents would be informational, so there would be no downref issue? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+i+w8ACgkQgItw+93Q 3WXK/QgAjFuSiKGypK4xtUeMGzvAiHI+WlVcA13ZbmMcnxHseesIIcmNaAux3roO N8yr6mguJ8V7PygAe0upEU5njuJUY5n9GEP2h+7+ZMtDJk/WyXnJCGgpcUSX7zTk 36XORqhwVns4Vm9+9JEUrzZxZo1LoFyoNA+tRW806031et3cUxVVkjhj44Wqoz5w +pwP7QDtfw73r5hSivNqt4p8c6SM8azyqCimKb7p1R13i0uDRziG5ppZTWPQzqXX RIWErxfPxJ9HKP0Fd8OeBRWNrCoxK7GhidB3pGQZefBdeOnqkGFQyj2Me3+53zik ammMH5qlkSXNE7tMznqcuJJby6QfUA== =305w -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 11:55:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8052D3A0A47 for ; Wed, 4 Nov 2020 11:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=oqQh86mV; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=qpgCRoXq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQpUP1I986pf for ; Wed, 4 Nov 2020 11:55:27 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA25E3A0A6C for ; Wed, 4 Nov 2020 11:55:26 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604519725; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kjkG9wWDN9SuVtL87lpCSrTUK7BRRcnWpkkhpy3LrGg=; b=oqQh86mVfbACxZw3WhrbBkrHw0mQ3i7WmPxwzR3wzFf5q0/my77sN/28QrOpTMDC6ukrP bGi058y452pRwFUDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604519725; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=kjkG9wWDN9SuVtL87lpCSrTUK7BRRcnWpkkhpy3LrGg=; b=qpgCRoXqEjFlYrHqU6q7FknVoxQR24iOaFBJinJE+LKOwZtggHESrRC/s1Cmq63rZMwRH CT1D19pOXUkCplq+MAua2pOrfX3FxGUfpmsS+UmXVNYBFsh6Sql46ySc7TgSPcX/pFkfuco xHT49H1tFAJ1R8gHiKZYLuVRu95SDi8D7aiKH/ZHjrF/BYft8idvuydZ4N9Vld1oRbAexym c2Q6Z67OyyWf6MRDhXQH+ooFnS/YxMPJ1g6F7st0bDfxW8cBjf0nkx/lT+yfpLyev2IJtHv 8YQdo7uOtot4/6agwwEmjDJj4w1C3fI3AlhEg1gkfeujP/DhODXpxXkqpGsQ== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7F283F9A5; Wed, 4 Nov 2020 14:55:25 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6BED8203CE; Wed, 4 Nov 2020 14:34:03 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley Cc: LAMPS WG In-Reply-To: <433E58C8-F027-4F4F-89FF-A97FA0E8D063@vigilsec.com> References: <87361pjjtu.fsf@fifthhorseman.net> <433E58C8-F027-4F4F-89FF-A97FA0E8D063@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 04 Nov 2020 14:34:01 -0500 Message-ID: <87sg9oj4ra.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:55:29 -0000 --=-=-= Content-Type: text/plain On Wed 2020-11-04 13:04:37 -0500, Russ Housley wrote: > My view is that the document would be very useful if the conclusions > from the experiment were at the front of the document, and then the > details of the experiment follow. I'm not sure which experiment you're talking about, Russ. While I've already used these certificates for things like header protection rendering tests, they've also been useful for exercising generic cryptographic functionality in several different MUAs, usability tests, sources for bug reports, etc. I want a simple, stable document that contains sample X.509v3 certificates and associated secret key material for use with S/MIME without associating these artifacts with any particular standardization effort. > Your I-D had a different intent, at least originally. The intent of this I-D was to offer generic certificates for use with S/MIME -- not about header protection specifically. I don't think the draft is (or should be) tied to header protection. > So, a restructuring now that the header-protection standards are used > would be another possibility. I'm hoping that the test vectors for the header protection draft (which will be MIME objects) will use these sample certificates. But i'm also hoping that other S/MIME drafts that include test vectors will feel free to use these certificates too. I'm hoping to add some test vectors in draft-dkg-e2e-mail-guidance, for example, and i'll use them there. That would make it much easier for people to set up their MUA for testing arbitrary functionality -- just load the default sample cert set, and then explore whatever you're exploring. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6MCKgAKCRDEDyVUMvKB D79tAPwOLQmPd6DDgNQIKYZfaNlL7pNhx9nuYutM7owXb31W8gEAk0PnFUGOnu4L m8YnApTfqjMXZPRjyJ1FAuVwxbTkOwE= =9Wtv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 4 12:06:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0803A0AA3 for ; Wed, 4 Nov 2020 12:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BRzUKdEh1fL for ; Wed, 4 Nov 2020 12:06:53 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BB43A0A80 for ; Wed, 4 Nov 2020 12:06:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9FA5C300B49 for ; Wed, 4 Nov 2020 15:06:50 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L8NUjQv7vHG3 for ; Wed, 4 Nov 2020 15:06:49 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 47851300B10; Wed, 4 Nov 2020 15:06:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <87sg9oj4ra.fsf@fifthhorseman.net> Date: Wed, 4 Nov 2020 15:06:50 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <82C17BBB-145D-43A4-8F12-3D98C4091706@vigilsec.com> References: <87361pjjtu.fsf@fifthhorseman.net> <433E58C8-F027-4F4F-89FF-A97FA0E8D063@vigilsec.com> <87sg9oj4ra.fsf@fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 20:06:55 -0000 DKG: > On Wed 2020-11-04 13:04:37 -0500, Russ Housley wrote: >=20 >> My view is that the document would be very useful if the conclusions >> from the experiment were at the front of the document, and then the >> details of the experiment follow. >=20 > I'm not sure which experiment you're talking about, Russ. When people sent you the screen shots for the way that various mail = clients rendered the samples. > While I've already used these certificates for things like header > protection rendering tests, they've also been useful for exercising > generic cryptographic functionality in several different MUAs, = usability > tests, sources for bug reports, etc. >=20 > I want a simple, stable document that contains sample X.509v3 > certificates and associated secret key material for use with S/MIME > without associating these artifacts with any particular = standardization > effort. Understood. I support this part. It was important for early S/MIME = interoperability, and it will probably be important as AEAD gets rolled = out for S/MIME 4.0. [snip] >> So, a restructuring now that the header-protection standards are used >> would be another possibility. >=20 > I'm hoping that the test vectors for the header protection draft = (which > will be MIME objects) will use these sample certificates. But i'm = also > hoping that other S/MIME drafts that include test vectors will feel = free > to use these certificates too. I'm hoping to add some test vectors in > draft-dkg-e2e-mail-guidance, for example, and i'll use them there. That seems like a good idea. > That would make it much easier for people to set up their MUA for > testing arbitrary functionality -- just load the default sample cert > set, and then explore whatever you're exploring. Some user agents make it easier than others, but that is not a reason to = stop. Russ From nobody Wed Nov 4 12:18:39 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9783A0A80 for ; Wed, 4 Nov 2020 12:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alAwqe176BFv for ; Wed, 4 Nov 2020 12:18:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E1A3A07E6 for ; Wed, 4 Nov 2020 12:18:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id ADCD038AB2; Wed, 4 Nov 2020 15:18:36 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Fb_EBdKfGsvK; Wed, 4 Nov 2020 15:18:36 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D62A138AB1; Wed, 4 Nov 2020 15:18:35 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C76AD13CF; Wed, 4 Nov 2020 15:18:31 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor , LAMPS WG In-Reply-To: <87v9elhsup.fsf@fifthhorseman.net> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 20:18:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > On Wed 2020-11-04 11:31:16 -0500, Michael Richardson wrote: >> I think that it's very very useful to have test vectors here. They >> need to be renewed regularly as algorithms and key sizes changes. O= ld >> ones are even valuable because they are expired. > The draft currently uses 2048-bit RSA keys, bound into certificates > that expire in ~2050. > My original intent was to *not* have the certificates expire in the > near future. I want to encourage the creation of test vectors that a= re > supposed to be technically valid for a decade or two at least. I agree that some stability is useful. Some certificates that expire past "xx50" would be good, since there was th= at Y2K hack, which I hope is now gone :-) > If we want deliberately expired certificates, i think we should > generate them such that they are already expired, so that people can > produce deliberately expired test vectors. Yes, I agree. > Note: i am a big fan of negative examples in test suites generally, b= ut > a catalog of all the ways that a certificate might *not* be valid in a +1 >> As an editorial nit, the various samples need to have , >> etc. and a file XXX so that they can be extracted easily. > Interesting! the draft uses a markdown-to-xml workflow (see the > Makefile in https://gitlab.com/dkg/lamps-samples) and i don't know how > to make that workflow generate or filenames. If anyone > has pointers to how to make that work, i'd welcome suggestions (merge > requests directly on gitlab would be bonus). I originally cheated, and I had created a perl script "insert-figures" before the era of kramdown, see: https://github.com/anima-wg/anima-bootstrap/blob/master/insert-figures is includes some support for tracking down the right YANG module. kramdown itself has an include: {::include ../ghc/packets-new/p4.out} you have to put in the stuff. I've mentioned this need to Carsten at some time. >> I also suggest you leave the --text output from openssl's x509 >> processor with the certificate for human consumption. > I'm not convinced that we want to embed the output of whatever > particular version of OpenSSL i happen to have on my computer today I don't care what you pretty printer you use, but I think that the human readable part has some value. > into the draft itself. People can use their preferred X.509 renderer > on the cert as given if they want to review it in more detail. The > goal of the draft is to describe the salient features in human terms, > and provide an object that any tool can be run against. In ten years, the renderer might print something different, and it might actually be valuable to know that something changed. > [ The certificates were originally generated with certtool from GnuTLS > (again, see the Makefile), not OpenSSL, not that it matters ] Good. I should use certtool more often myself. > Out of curiosity: how is one expected to encrypt an e-mail message to > an ECDSA or EDDSA S/MIME certificate? Or are those expected to be > signing-only certificates? Blush. Good point! I have no idea how ECDSA works with S/MIME encryption. > I've also committed the generated material so that the entropy involv= ed > in the key generation (picking large primes) and certificate creation > (datestamps and serial number) doesn't cause unnecessary churn in the > draft, but if there are problems with any of the sample certificates, > it should be pretty straightforward to tweak the generation steps, > destroy the artifacts, and have them be recreated. I think you are saying that the key generation is intentionally determinist= ic from a known seed? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+jDJcACgkQgItw+93Q 3WX5QQf+Pok2tpAR+DFh7yQJGjVBeGPn6mfBzYJE8VkoYtpC69ZCN3R6S6k1A+9a 9WN/sbMvRMCdifK2i7yG49JRE0uEDpbz3MBpHgMqSSu4+sIBMRW/S3nPSMP6wUWG AQfIGFVXRr4l54Ulyh34SmmJTy6Y1SRilzfLtBsC0Hvlda1Hxuxj+Ng/qvBxHFoc NDQbvNvUr6RLCGvukIhGu+RttHp+MW5RTd7nxQaI0R+uaGkT/xnYS//zlxrl92wX A/I2OuJX+LpBn21FY5dBje0U+VsbIqfbqlibyC89CXzaFp6srE1+RDfyl78UdmCS VFEu6CjhnPHAa6Y+1Iuiyc07+Pl3iw== =se0/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 5 06:57:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7CB3A17D6 for ; Thu, 5 Nov 2020 06:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=eyp9YQpq; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=gBCL42BG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU6KpXgd6RN7 for ; Thu, 5 Nov 2020 06:57:42 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22973A17D2 for ; Thu, 5 Nov 2020 06:57:42 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604588260; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=6K4vBpTz/6K1cFnWPpNnO5MukA4JPHtgDeNkq+LanqM=; b=eyp9YQpqsSTQHrImZciJkkVs0TVe275FTP/eem3uQPRucba4tMIMhUWrqerUhmqJaRt2D 98waLaUreRCLJ9ZDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604588260; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=6K4vBpTz/6K1cFnWPpNnO5MukA4JPHtgDeNkq+LanqM=; b=gBCL42BGodv4Yg3tUlanNV+3KOaCvugwYXFByI/K8XCYssIK3Ys4P0gNnHjtSQSmYicQp 3mHLe4bRrA+51YHdjM+tCkqkCJ+BkTrV7WqxC0/uBaUy6ymAPhOS7KKjVT7BjEB1IYMebgL 9wgwMaIOa430wqcbKBkicp4UOUjMt/yNAUqJN3WGTgJanHcIXX/zX0tGTVFBG2fFt+hbS+x kd/D7c8StBmNC0sAT/a6sW+EDAti/JfmYuNXWyWdNKxiZi6IGOwZLVNIk/9pMOeLI5WAw4J ZMavuD7jha4Sw1AuhhJijfgVbZFakihPkEm+trI3oLSdnjNZvH0+F6AhG3tg== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 69845F9A5; Thu, 5 Nov 2020 09:57:40 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A93052040F; Thu, 5 Nov 2020 09:52:47 -0500 (EST) From: Daniel Kahn Gillmor To: Michael Richardson , LAMPS WG In-Reply-To: <833.1604521111@localhost> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Thu, 05 Nov 2020 09:52:45 -0500 Message-ID: <87o8kbj1oi.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:57:45 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2020-11-04 15:18:31 -0500, Michael Richardson wrote: > I agree that some stability is useful. > Some certificates that expire past "xx50" would be good, since there was = that > Y2K hack, which I hope is now gone :-) you're talking about GeneralizedTime vs. UTCTime, i think? these certificates all are after 2050, so they do tickle that particular boundary. From the "alice" cert (in the ugly dumpasn1 rendering): [=E2=80=A6] 97 32: SEQUENCE { 99 13: UTCTime 20/11/2019 06:54:18 GMT 114 15: GeneralizedTime 27/09/2052 06:54:18 GMT : } [=E2=80=A6] > you have to put in the stuff. I've mentioned this need to > Carsten at some time. If there's an open bug report, i'd be happy to see it so i can weigh in! > I don't care what you pretty printer you use, but I think that the human > readable part has some value. [=E2=80=A6] > In ten years, the renderer might print something different, and it might > actually be valuable to know that something changed. The most valuable human-readable part is the stuff in English that introduces each certificate =E2=98=BA. And it's definitely valuable to know that a particular tool's rendering has changed, but i don't think that an RFC is the right place to record a changelog of renderer output for any particular tool. > I have no idea how ECDSA works with S/MIME encryption. Does anyone have a suggestion here? Is anyone on this list using either ECDSA or EDDSA with e-mail? > I think you are saying that the key generation is intentionally determini= stic > from a known seed? hah, i wish! my code (and my knowledge of the toolchains i'm using) is not that clever. I just ran the tools in the standard way, and took a snapshot of their output. Generating from a seed is a good idea for future work. =E2=80=A6does some reading=E2=80=A6 Looks like certtool has --provable and --seed options that can be used for this, at least for RSA and DSA key generation using FIPS PUB186-4 algorithms (i.e., Shawe-Taylor). I supposed for ECDSA or EDDSA key generation, we could just deterministically select (hard-code) the secret key based on a (correctly-sized) digest of a simple string. Thanks for the useful feedback and suggestions! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6QRvwAKCRDEDyVUMvKB D2XQAQD4eKgdR8iPhvTR/t0eoLB83KoNsJ2t9VpQo7N0VQE5xwD+JOaE8EYRxyVW Fk0njyqvJRvY3vReWSJLOwU6YVE6xA0= =/1GY -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 5 08:57:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B03A1850 for ; Thu, 5 Nov 2020 08:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 I-_cTCix5nu0 for ; Thu, 5 Nov 2020 08:57:31 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) (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 13F463A18AD for ; Thu, 5 Nov 2020 08:57:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ADRLIwKheK/rjLRW508edWK79VY2hMZm3cS2bi/KXXx8noLFsJHhxm2dk646+KSG8/DCR2BXBt8fMQxOOSqbOxTCYn0xwuT5WSzevq7+PY7sSROBGuwx7E5vTL5JpdBQS+xU3IBrJhs7V+KFdZKLOk9RbwrXigiX8eACsGe22y5rmEPUHNrHI+ld1X6zmopvceS2JJrZPKAenz5z5Ge0Mo0oLIanUJVORMHF/XLHyhvUF/bhacQEoBqpzPo9uWVG/AGyExr7jBPpecgG4AIGL1vacoBe6QFCYCfHieGBt42pF4FCIibuqMObJss/f8FwEqhQkOCEVwNexnEgXauplw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nEKxl85Uh72lm6NSsE+HBcQX5FhOT5QYVRQwpD54iHE=; b=nGAt+9mfSa5H7XJ4wfnk+PJv+VM0x6e6N6hQ7FE4OyUhFO+5+hfDkhWSeQVGA/YLaGW35aTyjD5sTy+I5CX2bemu9jGM39mBTHfAH1vgrjsHz7kssKg5942RuAOUQUlVU9Acm9YU/ekxM7rEBBleW7kyJKetDX/b7C21CDZAioMX6DEfU9ZI+v8aZjGdPSdOohJv+HPl5OvdDdzRRs6wQA8wtplvgObLfjD5YVTXqZ3yBWtO0GxtJ40BfOHwHrrUSozpqd67FSDD0/uEapsP9ykCvA6CEFh4zw40sR7/J0cAQ4x4hLCpHdbA0UBrP5NSuFmDNqj2ajjC+dsHSHGnvw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nEKxl85Uh72lm6NSsE+HBcQX5FhOT5QYVRQwpD54iHE=; b=jp1mme4VVzi3Lhbmc0zQO48SSXBdinJi7nsKrE/Wjl1UWQc8f3BpikGrIYPgHS0HnSUkvpeuGQBK79fX5y7y+Fx3twafcnCaoKwU+Wx3egSwLoUUKvxJPeMsS1uHxF/B0XbZILO3zrbUVIP7ch2FjMmq4IZpT/NoBLo2uUyEkpc= Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:7e::24) by VI1PR10MB2143.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:83::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Thu, 5 Nov 2020 16:57:26 +0000 Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b]) by VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b%7]) with mapi id 15.20.3541.021; Thu, 5 Nov 2020 16:57:26 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-01.txt Thread-Index: AQHWsSwPsW51yvKszka3+pqv4wUNFKm5xnlA Date: Thu, 5 Nov 2020 16:57:25 +0000 Message-ID: References: <160433046906.22846.13770850635129817305@ietfa.amsl.com> In-Reply-To: <160433046906.22846.13770850635129817305@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-05T16:57:24Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=a5698bea-a762-4b78-a373-a57264c4798e; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.175] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a8513003-f913-401a-639f-08d881abdf6f x-ms-traffictypediagnostic: VI1PR10MB2143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1850; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6o6TTiRfLqjzCf+0JTkh58kFKBG55SmEW5bHloslSrtUWXEj9bQlbNijjr/E6NmQTfM1ok6iALcu4h7utshoAYEtVVHhTY4SOSDc5P4xFdSI8qpUJhvSIRW2waq8Cdur07PjTA6w5eNJbqnbjQB8PZciU/d7MDFOh73iqpr8vyFP5FF1zGfmTGHaVygDLa1dA73p0P9HKFMUkfi/ueJfv2rAxAaSd/YqgGISAGc2PEK/cIR4dxw6VBn4wCUW4Bta6KXLR6e2KSkXr8ebhowCgWh+FOyRMEV12TzN3d+Ueccwj71ahB0SRSigCBGhVJ6CssQujYqxMHzabHsQHdlI3zYm0pyH+dntxYbH8/z2GpbNfp+WgtnrEEknuTQ0BczbRlwULGeb1ybIvBiNaRkgeQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(376002)(39860400002)(346002)(136003)(966005)(33656002)(71200400001)(55236004)(2906002)(86362001)(7696005)(76116006)(478600001)(6506007)(186003)(45080400002)(26005)(6916009)(83380400001)(66556008)(64756008)(66946007)(8936002)(66446008)(66476007)(66574015)(9686003)(55016002)(5660300002)(52536014)(8676002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yf9WxOA/fzpnJ0V4XfWYm60Myn3UM/e3jIvqyshacv+5H3DWkFGtz1IXX1kWu+cfn7Fv0/HtBbI1n4WHrO0RMBYniDDMdNtrRQbXC02jQkHjVFtteqJvSy4unXZNlEdKZ1VKIZlJtBQmHt8PaEVtMCxfpLyvcbarpvdIuONW8c/bSHfwNYnIzLs/skxM+prN+xrZonVlj0SUK9RMhmvgELG0gkr4+yV2PbThK71NJXJS1vlpriUEPEC82UaDfYIrlhI/5jpsT5Zkq+Ae9i9DHkmW0h5d3aVnXLMI5IgtqKLNoy3K3q0iAatPBptcOPb7bAjrbVnlffLjHse6smg7+dRVjh9eT/auvSOWTRCt+VWzUIrDqrxyyzEtAj6BQGNgSRPT/uM5k06W3QvavC+lOvXVkEzdW+0VAN/Ewkdbpx1q6tFuqfd+QEiw7YW0ffisKh9FoFjyC4Rs+fsh/CQ56B6gX6TVom/9+TvRVqprlPokabRSpDVz9eb4+DxNowKr29Jk89r3fmYUseoJ0eQGGYywGxR/7UgV/T9RXPWkbDjPFZVd/2cmGFRDFQ1VxtGeJ7oqLpQ12dmCRPLXNVVJAPr+BLln2OctxQcdpFSh2NQC4/s4NxYOAKtNZUBy2i+SVdj4H7x1hvXGdTEv1jCOQQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a8513003-f913-401a-639f-08d881abdf6f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 16:57:26.0095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UY38PCfEIf5Qo4MbCoDdsA7/pfUnLWjsa35J1ZEP2+Yd3dO2fg92uNsqNlfAQS0KiuNhHjme2OfheTNAYQpi5vApuZ0oou6DhiCIOMPUJOY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR10MB2143 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cmp-algorithms-01.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:57:34 -0000 This is now the first complete Draft as discussed at IETF 108. https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-algorithms/ The content is: 2. Message Digest Algorithms . . . . . . . . . . . . . . . . . . 3 2.1. SHA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 3 3.1. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Key Management Algorithms . . . . . . . . . . . . . . . . . . 5 4.1. Key Agreement Algorithms . . . . . . . . . . . . . . . . 6 4.1.1. Diffie-Hellman . . . . . . . . . . . . . . . . . . . 6 4.1.2. ECDH . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Key Transport Algorithms . . . . . . . . . . . . . . . . 7 4.2.1. RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Symmetric Key-Encryption Algorithms . . . . . . . . . . . 7 4.3.1. AES Key Wrap . . . . . . . . . . . . . . . . . . . . 8 4.4. Key Derivation Algorithms . . . . . . . . . . . . . . . . 8 4.4.1. Password-based Key Derivation Function 2 . . . . . . 8 5. Content Encryption Algorithms . . . . . . . . . . . . . . . . 9 5.1. AES . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Message Authentication Code Algorithms . . . . . . . . . . . 10 6.1. Password-based MAC . . . . . . . . . . . . . . . . . . . 10 6.2. Diffie-Hellman-based MAC . . . . . . . . . . . . . . . . 11 6.3. SHA2-based HMAC . . . . . . . . . . . . . . . . . . . . . 11 Any Feedback is welcome - Hendrik > Von: Spasm Im Auftrag von internet-drafts@ietf.o= rg > Gesendet: Montag, 2. November 2020 16:21 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : CMP Algorithms > Author : Hendrik Brockhaus > Filename : draft-ietf-lamps-cmp-algorithms-01.txt > Pages : 18 > Date : 2020-11-02 >=20 > Abstract: > This document describes the conventions for using several > cryptographic algorithms with the Certificate Management Protocol > (CMP). CMP is used to enroll and further manage the lifecycle of > X.509 certificates. >=20 >=20 > The IETF datatracker status page for this draft is: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp- > algorithms%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7 > Caa680ea7b53341729f1b08d87f4331c3%7C38ae3bcd95794fd4addab42e1495d > 55a%7C1%7C0%7C637399273856702196%7CUnknown%7CTWFpbGZsb3d8eyJW > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C10 > 00&sdata=3DbNVSx5s%2BZT6vKS0fi61h4wlhilCj93NO7ajRYyaGCgM%3D&am > p;reserved=3D0 >=20 > There are also htmlized versions available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-cmp-algorithms- > 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Caa680ea7b > 53341729f1b08d87f4331c3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399273856712193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3D%2F223fu7%2F8aAj6067JwcXQRskFS5TZdE1t0nRRiOvF0w%3D&reser > ved=3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-algorithms- > 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Caa680ea7b > 53341729f1b08d87f4331c3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399273856712193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3DaLxIVNyJG%2FzN%2FGQtDKEnxnS6RdBqd%2Fx6Ka9DcIRtAmQ%3D&r > eserved=3D0 >=20 > A diff from the previous version is available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-algorithms- > 01&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Caa680ea7b > 53341729f1b08d87f4331c3%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399273856712193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3DQI2ugJsqz%2BQAGeGT7PloekyGeM8asTNHL6ovlt24x54%3D&reserve > d=3D0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://eur01.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org% > 2Finternet- > drafts%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Caa6 > 80ea7b53341729f1b08d87f4331c3%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1%7C0%7C637399273856712193%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=3Dpls%2F0jMZ76z5LmHARRpB1FA69MkRYT%2F4kuk8BKKJIN4%3D&a > mp;reserved=3D0 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.brockha > us%40siemens.com%7Caa680ea7b53341729f1b08d87f4331c3%7C38ae3bcd957 > 94fd4addab42e1495d55a%7C1%7C0%7C637399273856712193%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI6Mn0%3D%7C1000&sdata=3DFEDV4Oy9KnvJAJXGbv9sqwoRZdVd7I8fB > mwtYRuC21k%3D&reserved=3D0 From nobody Thu Nov 5 09:00:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0F23A14A2 for ; Thu, 5 Nov 2020 09:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 gxDXGMcTrV-w for ; Thu, 5 Nov 2020 09:00:26 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2047.outbound.protection.outlook.com [40.107.21.47]) (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 5BA593A184B for ; Thu, 5 Nov 2020 09:00:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jP3O7eJY/CukC6dI1BqcZhx9kTP15xPy795IZ47mcrdS/vM5Zm/PcKg3KoyVvDe/gxTrS2R7q2Wio+fgKEZ+dOJt42F2UpmqzyE9qwtHPU78Nbrx645cbaiY9w2j+UT96OCBoZEjtxdmjKDtBUUl1Fh/PeF97EqpL3QEOqakYuTmt1j/xU/DrVVQGY45JS0HRenOPLrmcM3m6ButvF4dXDyfImNrtEJ0lk6QGdKuzYrgrjxczEK7HhYh+C30tca0rsMFPxE3EssqgDq9QIBLCCFwytHRTsMEzKAUsxQEX/jilf0TOuj1neDRq87lmeKF0f/I8ZBZiWrQTCsb5Wqtaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6sogbYqZ9FAoH0rSnDdutd+L8HAIWGDYxcctj3xmqqk=; b=flenDRo7w8yfrUmq8cB4uKZTnhXxZLWj5Sc1eC7v8OH42Uk3CbY9nhyvDJxRy/xkVtdXRjWPkEkR2g/2AZmGzB1Vu6/K9cygBUaGKo0tqneCGWFrPPF8zVdAG3QBYe1/AVKqDyeGW3jYhYBx0d39iI7qCGXsGRPcHz1D7OC8tF7WOEhCokf+C7CAzF3PVSelowZ4nXqWQid6/3reXJsnF/pKT753NwGPd4J9dv6MfbEMPbeEp0edszE33LxEiMHN+y7xnVGIoAXxr/OoRXR2o5ZSmMFcT7zJFRrJ+l2HXcJmySz6zK84Q47dywLYX+VhCXwQY1qkzWQLbmKCKEeLdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6sogbYqZ9FAoH0rSnDdutd+L8HAIWGDYxcctj3xmqqk=; b=OC4CifSTEnM++v8pwBua0FhUuFavhJrGApBhkeucyNO7BBHjg5Sx8/gv+LQS/5gnReg62Vt8kYbi3axpYDMA3VoACzPKPcSHIFe/6kKGHTKz1aQwOGlRrACLsipgkf68ICi7VffJKSSHtk4Nh7YEvplUMSfWrrs7Rd31Q8yZtEw= Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:7e::24) by VE1PR10MB3887.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:800:161::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Thu, 5 Nov 2020 17:00:22 +0000 Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b]) by VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b%7]) with mapi id 15.20.3541.021; Thu, 5 Nov 2020 17:00:22 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-06.txt Thread-Index: AQHWsSxlFZlbsLsH4EWuUGhL4bo6tKm5xzyA Date: Thu, 5 Nov 2020 17:00:22 +0000 Message-ID: References: <160433071583.14730.17876324264058960807@ietfa.amsl.com> In-Reply-To: <160433071583.14730.17876324264058960807@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-05T17:00:20Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=c85de1c2-080e-4ef6-8117-f02fb86755df; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.175] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e9783908-a229-4c2d-db79-08d881ac4871 x-ms-traffictypediagnostic: VE1PR10MB3887: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NeI2A3hxQK6uFEdUyQHughb9+UyzUd8tezmn3es0IivIgTKYVJn7DOAcGoVEBbe/S7xCrWJcF/8w+D0KfSQSSv5eZpJHX2OLKiiJDo5PdvbDbCsV9FgKUCn+46a/qOxS+bXwL8wOUYMiImjw61YAjOaFV0+erX0gZP+aNQGrWP63tSz1C0B14Pv3ENRQP+Iiel24fFEeQDBaf+m4SiLj+PUxAV84P1NsP7Svz/hYVYiskwSDF+XXzbkfFUcOhJPooJllpMgRjHpe+25lEFko8+bpzTXONH4qpqhKFtBvz7wV2WXa1IOKNPQi4w+RLw3674zX/dPVi2HuAuKJzGFtqG35dFfaYmCOC75Vqty0HiemNHTZDixOnyAA0YGrN3JZbQzZzbtOn/6NbSO7RrPqyA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(136003)(396003)(366004)(376002)(55236004)(6506007)(8676002)(8936002)(5660300002)(15650500001)(316002)(76116006)(71200400001)(2906002)(52536014)(26005)(66476007)(86362001)(186003)(66946007)(66574015)(7696005)(6916009)(83380400001)(45080400002)(478600001)(55016002)(66556008)(33656002)(966005)(9686003)(66446008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GP6fSrKYINSDkKe5/4PB7JeNhgjHnEbnCeQx9iWbN4huy6khOu/c+K98oyW5i+BAfZC8gZ1a6HeR71JaOwNPn/z70RdAhsCHQshs7zwO9Y85JqNFGULfMH/kDXbmFbLTTkd6wz15p7pO82CnTOrBDrQ+nPR2iTZFsJglFR31wiX7CnixloZvAynQC8UAVAt00DXoL0pkcpXAi1QFEpxdu2M67yHVJhvHwt6BBAOs1BrAEXXIrvuFDdCCtNOa/xLqicK2L/lYflyUyYUxNDJ2ktjLYwAXBxA2E56jO1Z7otfVYCXE7ko4zzK5Z0grHCxkHaDWQ20Ptw9n9a/J1XeHBgR5m3fu787Y2xiRkOaToq8bct+m1posjwUhQHDFGGZaq7krzrtegbDOS/FAid6DXMgbDt2q2WfzbZ5CJeXakoFYrL4M1tTI1oHfBXXxtEyda0XSChD2AmDM9iXqYanWMqnZC+dOStM4qWT5y2k4QLAJWuAda+WQyexGhLmB9xNWOtuQwOxIWP9Is7Nq0ih69yPwJxxH3lIUfr2ceNFIXSt7zfQU2o77W5jnODco3+U+RAAgFe9SbdUkX90qFzCy+fheoYgdlfoQbdTsCsJkFmryqikfBu9OH06k+y+gRue+NOl7VDqoZyCNSP77YrzVFA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e9783908-a229-4c2d-db79-08d881ac4871 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 17:00:22.1635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qVzE2t5zdmiZgccxrNZndvO2wUbyBC7PUc7MIRr++trpSHu4P/19lsDTPuOFop0zNEYfkf8oUMJv682aKXxC7Qd6OLZ5gSklcu3oeJi1m9Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR10MB3887 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:00:34 -0000 On Monday I uploaded a new version of CMP Updates. https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/ The updates since the last versions are: From version 05 -> 06: o Added the update of Appendix D.2 with the reference to the new CMP Al= gorithms document as decided in IETF 108 o Updated the IANA considerations to register new OIDs for id-regCtrl-a= lgId and d-regCtrl-rsaKeyLen. o Minor changes and corrections Any feedback is welcome! - Hendrik > Von: Spasm Im Auftrag von internet-drafts@ietf.o= rg > Gesendet: Montag, 2. November 2020 16:25 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : CMP Updates > Author : Hendrik Brockhaus > Filename : draft-ietf-lamps-cmp-updates-06.txt > Pages : 49 > Date : 2020-11-02 >=20 > Abstract: > This document contains a set of updates to the base syntax and > transport of Certificate Management Protocol (CMP) version 2. This > document updates RFC 4210 and RFC 6712. >=20 > Specifically, the CMP services updated in this document comprise the > enabling of using EnvelopedData instead of EncryptedValue, adding new > general message types, the definition of extended key usages to > identify certificates of CMP endpoints on certification and > registration authorities, and adds an HTTP URI discovery mechanism > and extend the URI structure. >=20 >=20 > The IETF datatracker status page for this draft is: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp- > updates%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb > 448adbcb0654aaa14d308d87f438720%7C38ae3bcd95794fd4addab42e1495d55 > a%7C1%7C0%7C637399275287296582%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000 > &sdata=3DpbYddw5o8%2B%2BUncsITxS1yl9M1szW6xzVESijU3Nddeo%3D&a > mp;reserved=3D0 >=20 > There are also htmlized versions available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-cmp-updates- > 06&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb448adbcb > 0654aaa14d308d87f438720%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399275287301573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3Ddx5QGzzM3LgGnXMWEoKg8hinh1Ot4qysm1Q1D0%2BqSAg%3D&res > erved=3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-cmp-updates- > 06&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb448adbcb > 0654aaa14d308d87f438720%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399275287301573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3DONi4NIMBzzAtP7qvSC8%2BAi4VhD0BejjtVW%2BG%2F7wTG8k%3D& > reserved=3D0 >=20 > A diff from the previous version is available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-cmp-updates- > 06&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb448adbcb > 0654aaa14d308d87f438720%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > C0%7C637399275287301573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s > data=3DpPD%2FpBQTpxZMRzptu6XdU4H2PcJIRZhUT1M91kNFPKI%3D&reser > ved=3D0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://eur01.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org% > 2Finternet- > drafts%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7Cb44 > 8adbcb0654aaa14d308d87f438720%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1%7C0%7C637399275287301573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=3DwM%2F5yLP1L%2Bnsk%2FOyqyXLitAow0DT6VCZyjGsEsCdd90%3D& > amp;reserved=3D0 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.brockha > us%40siemens.com%7Cb448adbcb0654aaa14d308d87f438720%7C38ae3bcd95 > 794fd4addab42e1495d55a%7C1%7C0%7C637399275287301573%7CUnknown% > 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL > CJXVCI6Mn0%3D%7C1000&sdata=3D1GE5TSDLJtMZTxAGChJFi2qzQ9e0H2a9 > Sf3tfUbUXzY%3D&reserved=3D0 From nobody Thu Nov 5 09:02:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE9D3A184E for ; Thu, 5 Nov 2020 09:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 ML8o6eqd5xnA for ; Thu, 5 Nov 2020 09:02:56 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2056.outbound.protection.outlook.com [40.107.21.56]) (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 CAEFA3A1853 for ; Thu, 5 Nov 2020 09:02:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c32giE7gehWkw5ix4lI80MMnePxAVEqXFdgv4YTQEwl4aqZaUZ7iMzCsrzEFuOgd6SfiQS4QH5+5WOx0wIkwxuuEkN4127X4OQn6FndZSnxGJ8kBt4JfkgKgmxmshPwcwreGrc/QY23FPBostDexGlPTRi+ifjXS84+UJLCDEuqoZJms7EwEEAdKIx3k3o6G9MrrUNQc/pBYX9GJsXBIwbvTrAZOqdHo4+5pqvUo8iPe88CHbBIlXmZEybtuOwwx+eqsCTZXyK+CF2PMyX6i82giNsAuSuuLPKm3g8Bo3QOgDo1+r9Jm8yARU1tz+J0Yy3QR9dC/BmRLxM8KRNi3xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s9s4kGsT2egVOwRmuuMP8hxCH/UyN78icjK41d/HpC4=; b=LgnXcG4h2+JK6p1IqnFUgx0ZfmUHp61f/3i7sKlbVi7hLRvygAoD6novixWdnh9SeL3EU2U7h/m4XiAkdAVaEAdyDyPhXc4Kxy5H3j4T14Xj2fOytSDiSkSOqLW4M3XndyYg8cj/Pwu4DzTbPi73imrPealapjcxxd/HpKXNL2V+z5ISVTwIU9GiBwvsjcn/L4xYM8khdnZAfJbzDIYhPDCIQk4KFhTbqA3r73+a4t7CR5tdcDsnSTS9krcvCMFnEL3Gw8gmpLp32l6PyyKUDFAQFAfynu8JjBxDQWvr8hMjTrW8Kqy4BB3cuAtUdMQ2e5ae6k7qBaMC4ip87uSkOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s9s4kGsT2egVOwRmuuMP8hxCH/UyN78icjK41d/HpC4=; b=OpwUwIwOa9cAUXTYlY0BXqByD7jrlpLUkdbY9n15QwijZFxkFZ6KC/y4BjI845AJKY8ckJAnd4mANx2PkhgYNrYEzEoZA/iKEV3EbaVCCntJBTuNNuvS2fxXj8+alhVmOfVy6H9HSbj5OZtEmMtuq35V5D4asOxt+f2TCcFHyzE= Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:7e::24) by VE1PR10MB3887.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:800:161::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.19; Thu, 5 Nov 2020 17:02:53 +0000 Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b]) by VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::4549:9825:81fc:8e2b%7]) with mapi id 15.20.3541.021; Thu, 5 Nov 2020 17:02:53 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-04.txt Thread-Index: AQHWsUfoBJTraAv/HU28GoEF7qpzvqm5x8aQ Date: Thu, 5 Nov 2020 17:02:53 +0000 Message-ID: References: <160434253431.25078.16760796070202783089@ietfa.amsl.com> In-Reply-To: <160434253431.25078.16760796070202783089@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-05T17:02:52Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=7e7369c0-f187-4371-ac87-5a531b321300; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.175] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 25e8d474-e846-47e8-304c-08d881aca28e x-ms-traffictypediagnostic: VE1PR10MB3887: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: quN2vJTWF4teTWeT+EfySX1bbfDVMsGlvViBeCEnKjP/7Mg0mRu4Ls2IVteoJ3dHe/UnLyAU1EwuIqa679NOo99VaLtAQzKMTR03SqUpNVLD74kaRTRT6Wgt7URe9ByJF6zCHUz1TTcZxfm0KGS9KTC8quZaa+NJyuiZNyENiHsjXz+6zVxGjfLMCDM8FrsStxaXg6Syzc9tH5JfMjkc1Il6aWxx+wn6qdCgzgdOBN6WxXV5bhpIv/I9aK9bDyOENMcPYJ6mK0fjHIHRcBbYaKuv07tURu6QvFDuvHUQ+tn0Nt8jWFQ0OJq4kuCxPd2ZtV1snxlZsNFjMd3x/pfhTCRPGxG8UOkyevE+T3BTKRi3Axh0R6uIFkjL1Ud3D8yyMp4wpjfg8yVkfcTSFspOXw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(55236004)(6506007)(8676002)(8936002)(5660300002)(76116006)(71200400001)(2906002)(52536014)(498600001)(26005)(66476007)(86362001)(186003)(66946007)(66574015)(7696005)(6916009)(83380400001)(45080400002)(55016002)(66556008)(33656002)(966005)(9686003)(66446008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: MkJAujYWd9BxfLeltaKTku8Kn6H6NjdOb12Ok1ybXU2Q4OvpGt4ZbiGJVCMVm/q1CYoeRu/0RvIJ3M90PwF2veUBtF6Gm65ataqHRtYRjHWj79pzU7mF4FiqfbToFdeOhRcHcNMyyMNvxjOtd43Pdp9ovuAOloe3qmoJ84sVf76vUV2n5T+L8ED5gu34RihYcq6rBDPD/FTz10f1bSBDmppTbVFcz+lSVp9YkW32wKtcqE8r5/GM6/S3cT7FkrkPU5z7rZRFlEZE9nAZ4wI1OQNqFrYFPs4RDe2nidXfW3xPt+9T8scRT9KDoviKfWaKwGkmAwdMIuu8XcHmvti4cK3mDevufxp943U7xZa2O8XG8ZMsui2Ryq1/QzvyNkHr/NbmTaFsVnTE2ij5ysjVsp6On/5UfvPx643FKMHItov1nYUvUgqoHa/MYPfS35dtPcbiMCNsjC3x5+G2Pg3i1gNcV6eXGcs4nlHZTBWFFEKK4gTQGpxzKLRpINShi2aOysvDvdBf+Guv/PUXr4OPi2z7cq/3hsii8G5trdqRFx1d6TXpuEHunZMevyRxaSLIzMx0+CEYuJPxaa9+HL7UbbE/ZoHnx5phJry9PzsbwxObg8/e1SmcwE3oYh+422bJEi8FTwon/t9Qo5GHfUCthA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 25e8d474-e846-47e8-304c-08d881aca28e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 17:02:53.3671 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pz/mZBlfVWKAWOtbp27Q5yGzZ0pmnlhrXM6cvd0AKBoylMw+Z/uKOZrixBxjfvWwwAO/KiDG61k8xb1qrYElt2QAsc1JcaH6qjzc9NnLcWc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR10MB3887 Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 17:02:58 -0000 Also uploaded on Monday, https://datatracker.ietf.org/doc/draft-ietf-lamps-= lightweight-cmp-profile/ The updates since the last version are: From version 03 -> 04: o Deleted normative text sections on algorithms and refer to CMP Algori= thms and CRMF Algorithm Requirements Update instead o Some clarifications and changes in wording Any feedback is welcome. - Hendrik > Von: Spasm Im Auftrag von internet-drafts@ietf.o= rg > Gesendet: Montag, 2. November 2020 19:42 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Limited Additional Mechanisms for PKIX a= nd > SMIME WG of the IETF. >=20 > Title : Lightweight CMP Profile > Authors : Hendrik Brockhaus > Steffen Fries > David von Oheimb > Filename : draft-ietf-lamps-lightweight-cmp-profile-04.txt > Pages : 81 > Date : 2020-11-02 >=20 > Abstract: > The goal of this document is to facilitate interoperability and > automation by profiling the Certificate Management Protocol (CMP) > version 2, the related Certificate Request Message Format (CRMF) > version 2, and the HTTP Transfer for the Certificate Management > Protocol. It specifies a subset of CMP and CRMF focusing on typical > use cases relevant for managing certificates of devices in many > industrial and IoT scenarios. To limit the overhead of certificate > management for more constrained devices only the most crucial types > of operations are specified as mandatory. To foster interoperability > in more complex scenarios, other types of operations are specified as > recommended or optional. >=20 >=20 > The IETF datatracker status page for this draft is: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fdraft-ietf-lamps-lightweight-cmp- > profile%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C9a > 9909d7e54f4104269e08d87f5f0aef%7C38ae3bcd95794fd4addab42e1495d55a% > 7C1%7C0%7C637399393458907606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000& > amp;sdata=3D6ABkCWHwoJKDIhckOuKEc%2FrH3eGcBopMZ8Jje7Wdt%2B8%3D&a > mp;reserved=3D0 >=20 > There are also htmlized versions available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 04&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C9a9909d7e > 54f4104269e08d87f5f0aef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637399393458907606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3Doh2M27gGLtexYFUWqXccYJGhK4Xl88VUTPfJNx8Qa%2FY%3D&reserved > =3D0 > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= rack > er.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 04&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C9a9909d7e > 54f4104269e08d87f5f0aef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637399393458907606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3DA3TcgAja50ekGhdkxnb%2BB5b8PMHSxgbDBvZ%2FQg5COXU%3D&rese > rved=3D0 >=20 > A diff from the previous version is available at: > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Frfcdiff%3Furl2%3Ddraft-ietf-lamps-lightweight-cmp-profile- > 04&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C9a9909d7e > 54f4104269e08d87f5f0aef%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637399393458907606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sda > ta=3D%2BAkfezV67GS4%2Bim%2FiOJZrVX5oU0SqUPU11QZTCiEIpk%3D&rese > rved=3D0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > https://eur01.safelinks.protection.outlook.com/?url=3Dftp%3A%2F%2Fftp.iet= f.org% > 2Finternet- > drafts%2F&data=3D04%7C01%7Chendrik.brockhaus%40siemens.com%7C9a9 > 909d7e54f4104269e08d87f5f0aef%7C38ae3bcd95794fd4addab42e1495d55a%7 > C1%7C0%7C637399393458907606%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a > mp;sdata=3DapWG6b%2FbQl0uCXFg0hJNsA8Ps66MpbVYsTokzJ%2BYryc%3D& > ;reserved=3D0 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf. > org%2Fmailman%2Flistinfo%2Fspasm&data=3D04%7C01%7Chendrik.brockha > us%40siemens.com%7C9a9909d7e54f4104269e08d87f5f0aef%7C38ae3bcd957 > 94fd4addab42e1495d55a%7C1%7C0%7C637399393458907606%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI6Mn0%3D%7C1000&sdata=3DbBG1iqkEFJ0EKmaYZpcJrlHflM%2BNUYvx > 6XiDfncPM1E%3D&reserved=3D0 From nobody Mon Nov 9 14:16:09 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F563A0E90 for ; Mon, 9 Nov 2020 14:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdrA_vieoofp for ; Mon, 9 Nov 2020 14:16:05 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB9E3A0803 for ; Mon, 9 Nov 2020 14:16:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9EA82300B19 for ; Mon, 9 Nov 2020 17:16:02 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MMKv5FgijT0c for ; Mon, 9 Nov 2020 17:16:00 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id D2AC2300AA4 for ; Mon, 9 Nov 2020 17:16:00 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C278A0FE-2E76-4496-BCAD-C98D6F776BD1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: References: <160495994266.7995.7929410254698161302@ietfa.amsl.com> To: LAMPS WG Date: Mon, 9 Nov 2020 17:16:02 -0500 X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] Fwd: New Version Notification for draft-housley-lamps-cms-aes-mac-alg-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 22:16:08 -0000 --Apple-Mail=_C278A0FE-2E76-4496-BCAD-C98D6F776BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I asked NIST to assign OIDs for AES-GMAC, and they did so very quickly. = Thanks to Quynh and Tim! This very short I-D describes the algorithm identifiers and provides the = ASN.1 module. Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-lamps-cms-aes-mac-alg-00.txt > Date: November 9, 2020 at 5:12:22 PM EST > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-lamps-cms-aes-mac-alg-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-lamps-cms-aes-mac-alg > Revision: 00 > Title: Using the AES-GMAC Algorithm with the = Cryptographic Message Syntax (CMS) > Document date: 2020-11-09 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-housley-lamps-cms-aes-mac-alg/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-aes-mac-alg > Htmlized: = https://tools.ietf.org/html/draft-housley-lamps-cms-aes-mac-alg-00 >=20 >=20 > Abstract: > This document specifies the conventions for using the AES-GMAC > Message Authentication Code algorithms with the Cryptographic = Message > Syntax (CMS) as specified in RFC 5652. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_C278A0FE-2E76-4496-BCAD-C98D6F776BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = asked NIST to assign OIDs for AES-GMAC, and they did so very quickly. =  Thanks to Quynh and Tim!

This very short I-D describes the algorithm identifiers and = provides the ASN.1 module.

Russ



From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-lamps-cms-aes-mac-alg-00.txt
Date: = November 9, 2020 at 5:12:22 PM = EST
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-lamps-cms-aes-mac-alg-00.txt
has = been successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-housley-lamps-cms-aes-mac-alg
Revision: 00
Title:= = Using the AES-GMAC Algorithm with the Cryptographic Message = Syntax (CMS)
Document date: 2020-11-09
Group:= = Individual Submission
Pages: 7
URL: =            https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac= -alg-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-lamps-cms-aes-ma= c-alg/
Htmlized: =       https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-a= es-mac-alg
Htmlized: =       https://tools.ietf.org/html/draft-housley-lamps-cms-aes-mac-alg= -00


Abstract:
  This document specifies the conventions for = using the AES-GMAC
  Message Authentication = Code algorithms with the Cryptographic Message
=   Syntax (CMS) as specified in RFC 5652.




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

The IETF Secretariat



= --Apple-Mail=_C278A0FE-2E76-4496-BCAD-C98D6F776BD1-- From nobody Mon Nov 9 14:38:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6213A149D for ; Mon, 9 Nov 2020 14:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Yc7Q7dtz; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=dfd7e0s6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_RTjhhxgC0D for ; Mon, 9 Nov 2020 14:38:05 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C9F3A149B for ; Mon, 9 Nov 2020 14:38:05 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604961483; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=WFVz3E1fdMXHtuO8c3Y+NSfhSf77shlIQv1ZFGV83qU=; b=Yc7Q7dtz2qRuz7VnAmRGTk2QWpiFKkXUnGqDRoK969qup/BCaro+JzeS99U6bZ6RMLiS+ aOTD2JBQKWFlQ4LCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604961483; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=WFVz3E1fdMXHtuO8c3Y+NSfhSf77shlIQv1ZFGV83qU=; b=dfd7e0s6nfX1bAFvMze47Gv5yns5rd2vzNt01QLfSpT963gb1637i0jdov7OE9d9A556w NyWpa5MZu5MUDMgraOXV9AJR4h9o16qhoJGgMCGnuBG+kiUGb1I4Wc+LYtmLkc4ZyLfmqMj vRfBpiBwcZnEy4dBxaoYcDB0zeYizI+4TynrcUoV6sjHpmyIZRfDq54eTZWMxQEkF6iHwwD lTLXdqT1agWWCcS5qciKz0A7rmjLMgfcC/kAVh4U+yPfs1NUxOUB1RI0NI+f7wMelSY1EwR Z8MVDiqoYD/0WQ6XXev3Qgkvd0uFeHawcVAy4ylHcL7yY/coa09jhejFuZ4w== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CD532F9A5; Mon, 9 Nov 2020 17:38:03 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 25E7220324; Mon, 9 Nov 2020 17:37:39 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , Bernie Hoeneisen Cc: IETF LAMPS WG In-Reply-To: References: Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 09 Nov 2020 17:37:38 -0500 Message-ID: <87r1p2gnrh.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] HP Issue: Bcc Handling X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 22:38:07 -0000 --=-=-= Content-Type: text/plain On Fri 2020-10-02 10:33:10 -0400, Russ Housley wrote: > Please take a look at RFC 5322, Section 3.6.3. The proposed direction > seems to be consistent, but you probably want to cite this section. Thanks for this pointer, Russ. Bcc is a surprisingly tricky thing to get right in all cases. In addition to the guidance in the section you cite, there are unusual tricks or special cases that responsible MUAs will want to do to deal with Bcc in "Sent" folders and "Drafts" folders (the semantics of these folders in most MUAs are subtly different from other folders, and from each other). Also, there are some subtleties when dealing with Bcc for encrypted e-mail (regardless of header protection) -- i've added a note in the to-do list in https://gitlab.com/dkg/e2e-mail-guidance to try to flesh those out. But after some discussion with Alexey and Bernie, i think we're reaching the conclusion that as complex as the work around Bcc is, it's pretty much orthogonal to protected headers -- if you are doing the right thing with Bcc already, you're likely going to do the right thing with Bcc when generating a message with protected headers and Bcc. (Conversely, a MUA that screws up Bcc isn't likely to magically get it right because they're implementing protected headers) I'll make an edit to the header protection draft that simplifies the text about Bcc, includes the reference you mention above, and otherwise doesn't drag the draft into too much detail. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6nEsgAKCRDEDyVUMvKB D5GpAPwPCDo/yaxEKBhuVqDpiJfg1mcYwqLcUduGIeKL1vm0TAEA7jn6g1DQD4Sx FRD/TG0w2XiQ+TxgL+ePCgY/zMrp7wM= =znAE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 9 15:29:36 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CF43A1418 for ; Mon, 9 Nov 2020 15:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQ6KkpO-EMF2 for ; Mon, 9 Nov 2020 15:29:34 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4383A0FCE for ; Mon, 9 Nov 2020 15:29:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 876C1300BB6 for ; Mon, 9 Nov 2020 18:29:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7eiFfSLu6Mqj for ; Mon, 9 Nov 2020 18:29:29 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4A472300435; Mon, 9 Nov 2020 18:29:29 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_946BB07C-9DE8-4D11-8B52-A358880D7C4E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 9 Nov 2020 18:29:30 -0500 In-Reply-To: <87r1p2gnrh.fsf@fifthhorseman.net> Cc: Bernie Hoeneisen , IETF LAMPS WG To: Daniel Kahn Gillmor References: <87r1p2gnrh.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] HP Issue: Bcc Handling X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2020 23:29:36 -0000 --Apple-Mail=_946BB07C-9DE8-4D11-8B52-A358880D7C4E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii DKG: > On Fri 2020-10-02 10:33:10 -0400, Russ Housley wrote: > >> Please take a look at RFC 5322, Section 3.6.3. The proposed direction >> seems to be consistent, but you probably want to cite this section. > > Thanks for this pointer, Russ. Bcc is a surprisingly tricky thing to > get right in all cases. > > In addition to the guidance in the section you cite, there are unusual > tricks or special cases that responsible MUAs will want to do to deal > with Bcc in "Sent" folders and "Drafts" folders (the semantics of these > folders in most MUAs are subtly different from other folders, and from > each other). Also, there are some subtleties when dealing with Bcc for > encrypted e-mail (regardless of header protection) -- i've added a note > in the to-do list in https://gitlab.com/dkg/e2e-mail-guidance to try to > flesh those out. > > But after some discussion with Alexey and Bernie, i think we're reaching > the conclusion that as complex as the work around Bcc is, it's pretty > much orthogonal to protected headers -- if you are doing the right thing > with Bcc already, you're likely going to do the right thing with Bcc > when generating a message with protected headers and Bcc. (Conversely, > a MUA that screws up Bcc isn't likely to magically get it right because > they're implementing protected headers) > > I'll make an edit to the header protection draft that simplifies the > text about Bcc, includes the reference you mention above, and otherwise > doesn't drag the draft into too much detail. Good observations. Sounds like a reasonable way forward. Russ --Apple-Mail=_946BB07C-9DE8-4D11-8B52-A358880D7C4E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCX6nQ2gAKCRCK5O7Q9ZwR y+/EAKDUDuaOvECTRU0TJ8H4oGY6meOJLACdHKnQrNaVjRPJsxZOecEKhqAykDE= =0txE -----END PGP SIGNATURE----- --Apple-Mail=_946BB07C-9DE8-4D11-8B52-A358880D7C4E-- From nobody Tue Nov 10 01:43:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65FE3A0D51 for ; Tue, 10 Nov 2020 01:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrrki7o3hoTX for ; Tue, 10 Nov 2020 01:43:54 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3163A0D4B for ; Tue, 10 Nov 2020 01:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605001433; d=isode.com; s=june2016; i=@isode.com; bh=toF92SqDMRLCfPMiwXRIHraSquEutONo05iGiwOvh64=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FwxSjwUvkr3YfExjUuPqNqKe/hLRSHmH6NE4wtfDdYVqeXpXIfa2vymrG62kNIKzqsRBO0 ijF5Vmsv8JfI4nEh84SWguv3EESyI/S7qb0inU5Zo91tGmmD+mR9tR39OetB4YpV4ToAdD Wzyq78w0MUrNIMJB7K6R5Q8bc8qmW7M=; Received: from [192.168.1.222] (host5-81-100-6.range5-81.btcentralplus.com [5.81.100.6]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Nov 2020 09:43:52 +0000 To: Russ Housley , Daniel Kahn Gillmor Cc: IETF LAMPS WG References: <87r1p2gnrh.fsf@fifthhorseman.net> From: Alexey Melnikov Message-ID: <9c06d4ae-4e3a-a8ec-77d5-7b6486ba8dcb@isode.com> Date: Tue, 10 Nov 2020 09:43:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [lamps] HP Issue: Bcc Handling X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 09:43:56 -0000 Hi all, On 09/11/2020 23:29, Russ Housley wrote: > DKG: > >> On Fri 2020-10-02 10:33:10 -0400, Russ Housley wrote: >> >>> Please take a look at RFC 5322, Section 3.6.3. The proposed direction >>> seems to be consistent, but you probably want to cite this section. >> Thanks for this pointer, Russ. Bcc is a surprisingly tricky thing to >> get right in all cases. >> >> In addition to the guidance in the section you cite, there are unusual >> tricks or special cases that responsible MUAs will want to do to deal >> with Bcc in "Sent" folders and "Drafts" folders (the semantics of these >> folders in most MUAs are subtly different from other folders, and from >> each other). Also, there are some subtleties when dealing with Bcc for >> encrypted e-mail (regardless of header protection) -- i've added a note >> in the to-do list in https://gitlab.com/dkg/e2e-mail-guidance to try to >> flesh those out. >> >> But after some discussion with Alexey and Bernie, i think we're reaching >> the conclusion that as complex as the work around Bcc is, it's pretty >> much orthogonal to protected headers -- if you are doing the right thing >> with Bcc already, you're likely going to do the right thing with Bcc >> when generating a message with protected headers and Bcc. (Conversely, >> a MUA that screws up Bcc isn't likely to magically get it right because >> they're implementing protected headers) >> I'll make an edit to the header protection draft that simplifies the >> text about Bcc, includes the reference you mention above, and otherwise >> doesn't drag the draft into too much detail. > Good observations. Sounds like a reasonable way forward. To clarify my position: I am happy to take Bcc discussion out of the Header Protection draft, but I would still like to do this work in LAMPS. Best Regards, Alexey From nobody Tue Nov 10 10:20:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765C93A0DF8 for ; Tue, 10 Nov 2020 10:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99wl_iILxWCP for ; Tue, 10 Nov 2020 10:20:50 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 76B393A0BA1 for ; Tue, 10 Nov 2020 10:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605032449; d=isode.com; s=june2016; i=@isode.com; bh=Lx/o1eSJ55/TIwPq8jvmZT0s5yewF0fJk4LvP7XbzHo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HVkyvsVttrERDmvAy0zlnkNuV9pb5+pG8z7GJoWFXornC2Po6lep36Y98pAwYLGj6uNTKU MMBS0cAxt+etjHbvFxsoQceskuVUIg7CMeVki+FKRRQyQ5j7VTZfG1z7QykHihzSIT//pk 3F9flIgkWzonWi/zOOgiqs6ieHu8oMY=; Received: from [172.27.253.13] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Nov 2020 18:20:49 +0000 To: LAMPS WG From: Alexey Melnikov Message-ID: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> Date: Tue, 10 Nov 2020 18:20:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [lamps] Proposal to adopt "Guidance on End-to-End E-mail Security" (draft-dkg-lamps-e2e-mail-guidance-00) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:20:51 -0000 Hi all, I would like to propose that this document to be adopted by LAMPS. It will be a dependency for the Header Protection draft and I think 2 drafts have complementary scopes. Best Regards, Alexey From nobody Tue Nov 10 23:20:01 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF4F3A0A07 for ; Tue, 10 Nov 2020 23:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=wAqqrT+i; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=rTbZKKY3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKQpuWbLsJ2a for ; Tue, 10 Nov 2020 23:19:57 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBCF3A09FF for ; Tue, 10 Nov 2020 23:19:57 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605079196; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=6BSD2Dd6EcRDjy1qXUcRYqFHLbfTzl7DHuxyCuCNKdE=; b=wAqqrT+ixw/T/lhRdjhILWupu2xHkV1r4lZx8FqvXngyUAbpvWOKS1BdpDd7OsQTbRj7d lozeVFbNiLFx4ZCCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605079196; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=6BSD2Dd6EcRDjy1qXUcRYqFHLbfTzl7DHuxyCuCNKdE=; b=rTbZKKY3dByuKTt7nGnwtXqNXCggAJbpbrBSYv9dXY3rqq/jEizIJIgRqWC6zmh9uHjPp ZbVvKO6avFS3j1IUJFmmsnQPWJz9bsgvwV3F8JrY7fb1R8OwUK3H18zIfEexjWSaYMdqyWs AvzBLQH0RbKaPkgF7puJSKosKNR4GKtqRrxfx7neez6LHtEOPBq1Y0vLprQTJrnmlEaaLIC oUIIRgy9TlhX9ADe4gljGamCmRCtjCLAVE3P9oNGzd1EAZNXRMH4NNSZBEHQgMFzCNS+oL1 YL4QZWkMcA/m6OZOLmE8ca8TR0CeAlY20TSyHb+aQ5n008v3pMA4L4JIaf6A== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 3256AF9A8 for ; Wed, 11 Nov 2020 02:19:56 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A173720324; Wed, 11 Nov 2020 02:14:29 -0500 (EST) From: Daniel Kahn Gillmor To: spasm@ietf.org Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 11 Nov 2020 02:14:28 -0500 Message-ID: <87o8k4gyaz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [lamps] Protected Headers update: proposed guidance for composing MUAs X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 07:19:59 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Hi folks! More followup on the header protection work! After settling on the guidance for receiving MUAs back on November 2-4, Bernie and Alexey and I met recently to discuss the rest of the ongoing work. This message contains text that is intended as guidance for MUAs that compose a message with protected headers (the "sending side"). This section describes how to create cryptographic e-mail with header protection using both identified schemes: "Wrapped Message" and "Injected Headers", in the same way that the earlier discussion about the receiving side documents them both. The difference here is of course that composing MUA has a decision to make about what to generate -- the receiving MUA has to deal with whatever it sees. The text as currently written doesn't have an opinion about what that choice should be -- but obviously we will need to make that decision before we finalize the document. It's in as a TODO item. My goal with this intermediate version is just to spell out very clearly what steps a composing MUA should take should they decide to use one scheme or another. The overall outline of this section looks like: * Sending Side *.1 Composing a Cryptographically-Protected Message Without Header Protection *.2 Header Confidentiality Policy *.3 Composing with "Wrapped Message" Header Protection *.4 Composing with "Injected Headers" Header Protection *.5 Choosing Between Wrapped Message and Injected Headers One novel thing in this writeup is the declaration of a "Header Confidentiality Policy" (section *.2) or "HCP", which is a special shorthand for describing how protected headers in *encrypted* messages should be granted confidentiality. The proposed text below contains one example (very conservative) HCP that only provides confidentiality for the "Subject" header value. In my next protected header message to this list, i'll document another (more aggressive) HCP. The final document will need to recommend one as a default (or perhaps as a baseline), but again, that's a simple outstanding TODO item. Feedback welcome, as always! --dkg --=-=-= Content-Type: text/markdown; charset=utf-8 Content-Disposition: inline; filename=sending-protected-headers.mkd Content-Transfer-Encoding: quoted-printable ### Sending Side This section describes the process an MUA should use to apply cryptographic= protection to an e-mail message with header protection. We start by describing the legacy message composition process as a baseline. #### Composing a Cryptographically-Protected Message Without Header Protect= ion {#compose-legacy} [I-D.dkg-lamps-e2e-mail-guidance] describes the typical process for a legac= y crypto MUA to apply cryptographic protections to an e-mail message. That guidance and terminology is replicated here for reference: =2D `origbody`: the traditional unprotected message body as a well-formed M= IME tree (possibly just a single MIME leaf part). As a well-formed MIME tree, `origbody` already has structural headers (`C= ontent-*`) present. =2D `origheaders`: the intended non-structural headers for the message, rep= resented here as a list of `(h,v)` pairs, where `h` is a header field name = and `v` is the associated value. Note that these are header fields that the MUA intends to be visible to t= he recipient of the message. In particular, if the MUA uses the `Bcc` header during composition, but p= lans to omit it from the message (see section 3.6.3 of [RFC5322]), it will = not be in `origheaders`. =2D `crypto`: The series of cryptographic protections to apply (for example= , "sign with the secret key corresponding to X.509 certificate X, then encr= ypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Pa= yload), wraps the input in the appropriate Cryptographic Envelope, and retu= rns the resultant MIME tree as output. The algorithm returns a MIME object that is ready to be injected into the m= ail system: =2D Apply `crypto` to `origbody`, yielding MIME tree `output` =2D For each header name and value `(h,v)` in `origheaders`: - Add header `h` of `output` with value `v` =2D Return `output` #### Header Confidentiality Policy {#header-confidentiality-policy} When composing an encrypted message with protected headers, the composing M= UA needs a Header Confidentialiy Policy. In this document, we represent that Header Confidentiality Policy as a func= tion `hcp`: =2D `hcp(name, val_in) =E2=86=92 val_out`: this function takes a header fie= ld name `name` and initial value `val_in` as arguments, and returns a repla= cement header value `val_out`. If `val_out` is the special value `null`, it mean that the header in ques= tion should be omitted from the set of headers visible outside the Cryptogr= aphic Envelope. For example, an MUA that only obscures the `Subject` header field by replac= ing it with the literal string `...` and does not offer confidentiality to = any other header fields would be represented as (in pseudocode): ``` hcp(name, val_in) =E2=86=92 val_out: if name is 'Subject': return '...' else: return val_in ``` Note that such a policy is only needed when the end-to-end protections incl= ude encryption (confidentiality). No comparable policy is needed for other end-to-end cryptographic protectio= ns (integrity and authenticity), as they are simply uniformly applied so th= at all header fields known by the sender have these protections. This asymmetry is an unfortunate consequence of complexities in message del= ivery systems, some of which may reject, drop, or delay messages where all = headers are removed from the top-level MIME object. This document does not mandate any particular Header Confidentiality Policy= , though it offers guidance for MUA implementers in selecting one in {{defa= ult-hcp}}. Future documents may recommend or mandate such a policy for an MUA with spe= cific needs. Such a recommendation might be motivated by descriptions of metadata-derive= d attacks, or stem from research about message deliverability, or describe = new signalling mechanisms, but these topics are out of scope for this docum= ent. #### Composing with "Wrapped Message" Header Protection {#compose-wrapped-m= essage} To compose a message using "Wrapped Message" header protection, we use thos= e inputs described in {{compose-legacy}} plus the Header Confidentiality Po= licy `hcp` defined in {{header-confidentiality-policy}}. The new algorithm is: =2D For header name and value `(h,v)` in `origheaders`: - Add header `h` of `origbody` with value `v` =2D If any of the header fields in `origbody`, including headers in the nes= ted internal MIME structure, contain any 8-bit UTF-8 characters (see sectio= n section 3.7 of [RFC6532]): - Let `payload` be a new MIME part with one header: `Content-Type: messag= e/global; forwarded=3Dno`, and whose body is `origbody`. =2D Else: - Let `payload` be a new MIME part with one header: `Content-Type: messag= e/rfc822; forwarded=3Dno`, and whose body is `origbody`. =2D Apply `crypto` to `payload`, yielding MIME tree `output` =2D If `crypto` contains encryption: - Create new empty list of header field names and values `newh` - For header name and value `(h,v)` in `origheaders`: - Let `newval` be `hcp(h, v)` - If `newval` is not `null`: - Append `(h,newval)` to `newh` - Set `origheaders` to `newh` =2D For header name and value `(h,v)` in `origheaders`: - Add header `h` of `output` with value `v` =2D Return `output` Note that the Header Confidentiality Policy `hcp` is ignored if `crypto` do= es not contain encryption. This is by design. #### Composing with "Injected Headers" Header Protection {#compose-injected= -headers} To compose a message using "Injected Headers" header protection, the compos= ing MUA needs one additional input in addition to the Header Confidentialit= y Policy `hcp` defined in {{header-confidentiality-policy}}. =2D `legacy`: a boolean value, indicating whether any recipient of the mess= age is believed to have a legacy client. If all recipients are known to implement this draft, `legacy` should be s= et to `false`. (How a MUA determines the value of `legacy` is out of scope for this docu= ment; an initial implementation can simply set it to `true`) The revised algorithm for applying cryptographic protection to a message is= as follows: =2D Create a new MIME leaf part `legacydisplay` with header `Content-Type: = text/plain; protected-headers=3D"v1"` and an empty body. =2D if `crypto` contains encryption, and `legacy` is `true`: - For each header name and value `(h,v)` in `origheaders`: - If `h` is user-facing (see {{I-D.autocrypt-lamps-protected-headers}}): - If `hcp(h,v)` is not `v`: - Add `h: v` to the body of `legacydisplay`. For example, if `h` i= s `Subject`, and `v` is `lunch plans?`, then add the line `Subject: lunch p= lans?` to the body of `legacydisplay` =2D If the body of `legacydisplay` is empty: - Let `payload` be MIME part `origbody`, discarding `legacydisplay` =2D Else: (body of `legacydisplay` is not empty) - Construct a new MIME part `wrapper` with `Content-Type: multipart/mixed` - Give `wrapper` exactly two subparts: `legacydisplay` and `origbody`, in= that order. - Let `payload` be MIME part `wrapper` =2D For each header name and value `(h,v)` in `origheaders`: - Add header `h` of MIME part `payload` with value `v` =2D Set the `protected-headers` parameter on the `Content-Type` of `payload= ` to `v1` =2D Apply `crypto` to `payload`, producing MIME tree `output` =2D If `crypto` contains encryption: - Create new empty list of header field names and values `newh` - For header name and value `(h,v)` in `origheaders`: - Let `newval` be `hcp(h, v)` - If `newval` is not `null`: - Add `newh[h]` to `newval` - Set `origheaders` to `newh` =2D For each header name and value `(h,v)` in `origheaders`: - Add header `h` of `output` with value `v` =2D Return `output` Note that both new parameters (`hcp` and `legacy`) are effectively ignored = if `crypto` does not contain encryption. This is by design, because they are irrelevant for signed-only cryptographi= c protections. #### Choosing Between Wrapped Message and Injected Headers When composing a message with end-to-end cryptographic protections, an MUA = SHOULD protect the headers of that message as well as the body. An MUA MAY protect the headers of any outbound message using either the "Wr= apped Message" or the "Injected Headers" style of protection. See {{backward-compatibility-use-cases}} for more discussion about reasons = to choose one mechanism or another. \[\[ TODO: this document should recommend generation of one particular sche= me by default for new implementers \]\] --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6uPVAAKCRDEDyVUMvKB D1gVAP4mdX2aWCWWiAShQiFGwhtbeaO0cy4ej6504ojKZhiKQAD7BxUjPdfsuXz5 CMpBOZ2YKCad48S+IZ5CR0kP0KD7VAs= =bO43 -----END PGP SIGNATURE----- --==-=-=-- From nobody Tue Nov 10 23:20:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC33A09FF for ; Tue, 10 Nov 2020 23:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=qHcTpwfF; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=mFgp8qf6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLS-aabEU6qB for ; Tue, 10 Nov 2020 23:19:57 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8023A09CC for ; Tue, 10 Nov 2020 23:19:56 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605079195; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=Ne1plnyBJs5zTD0O9KeifDqek0vwph7sziRB8MaFVTI=; b=qHcTpwfF0E3OqJeGkzhDurCMZsuaT/FD3ZZ+vo9PsYRcHccc86zVzTZ9bCOospqNE/lTH KiagDT87h4KEQEtBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605079195; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=Ne1plnyBJs5zTD0O9KeifDqek0vwph7sziRB8MaFVTI=; b=mFgp8qf6sDD3b4X1vC/2c6+qnCWe3C5X2Nsq7pmdyhSGIfuZ3HXdL+Z8hW99+kZZ4CTb3 03B48i+5xuDEHqCLc0gQS/g7I65+DhdQFnxnBRfP4xtWqJRWLAORqfMwVwsmd6d0Cw//bS9 Wrzz9AHWeXiH+v2IVU05YPPuXKTGui2+p8HeUiNb9wByQ67AE/qexngu943pMmtMQvFWQNQ khexgDBMF6LGS92h65LuFs4dkK5yeKwvU9Mf6X4wTj159v8FPxOkurLEKV7x6zYRZyRCZuP h2oBt0j20aaMK+do+owVMNnx/+O4bFSBUpWTk+/XGf8Aqw7Rbl3KVI8j3dHA== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D4912F9A7 for ; Wed, 11 Nov 2020 02:19:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9C23020415; Wed, 11 Nov 2020 02:19:52 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 11 Nov 2020 02:19:51 -0500 Message-ID: <87lff8gy20.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 07:19:59 -0000 --=-=-= Content-Type: text/plain Hi LAMPS folks-- Alexey mentioned to me the other day that there might be an X.509v3 extension with the semantics "do not bother checking CRLs (or OCSP?) for this certificate" I looked for it, but i couldn't find it. Can someone identify it for me? Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6uQmAAKCRDEDyVUMvKB D8W6AQCTjuyw+8qEDpE20RTUuYr283R+ex4Mq12OT88OdVYS9gD+PDFWloNkZ2Y8 gNAOvtViDAwkMU0Q2TAltA3Pv2cCawc= =yvtN -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 11 00:37:06 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA303A0EDF for ; Wed, 11 Nov 2020 00:37:05 -0800 (PST) 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETstddWJzUCn for ; Wed, 11 Nov 2020 00:37:03 -0800 (PST) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92CBA3A0EDE for ; Wed, 11 Nov 2020 00:37:03 -0800 (PST) Received: from mistress.home.hezmatt.org (2001-44b8-510e-8600-e811-dc6a-d0ae-8f9b.static.ipv6.internode.on.net [IPv6:2001:44b8:510e:8600:e811:dc6a:d0ae:8f9b]) by mail.hezmatt.org (Postfix) with ESMTPSA id 778AA1A15D8 for ; Wed, 11 Nov 2020 08:37:00 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id B8BBDA0E3A; Wed, 11 Nov 2020 19:36:52 +1100 (AEDT) Date: Wed, 11 Nov 2020 19:36:52 +1100 From: Matt Palmer To: spasm@ietf.org Message-ID: <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> References: <87lff8gy20.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lff8gy20.fsf@fifthhorseman.net> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 08:37:05 -0000 On Wed, Nov 11, 2020 at 02:19:51AM -0500, Daniel Kahn Gillmor wrote: > Alexey mentioned to me the other day that there might be an X.509v3 > extension with the semantics "do not bother checking CRLs (or OCSP?) for > this certificate" > > I looked for it, but i couldn't find it. Can someone identify it for > me? He may be thinking of id-pkix-ocsp-nocheck, from RFC6960 (s4.2.2.2.1). - Matt From nobody Wed Nov 11 08:07:49 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDDF3A0C8E for ; Wed, 11 Nov 2020 08:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZzp8dhiQYS6 for ; Wed, 11 Nov 2020 08:07:45 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F253A098D for ; Wed, 11 Nov 2020 08:07:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4A396300B22 for ; Wed, 11 Nov 2020 11:07:43 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3HhEWNzltC3Z for ; Wed, 11 Nov 2020 11:07:41 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BBEAB300A9E; Wed, 11 Nov 2020 11:07:41 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 11 Nov 2020 11:07:43 -0500 References: <87lff8gy20.fsf@fifthhorseman.net> <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> To: Matt Palmer , IETF LAMPS WG In-Reply-To: <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:07:47 -0000 > On Nov 11, 2020, at 3:36 AM, Matt Palmer wrote: > > On Wed, Nov 11, 2020 at 02:19:51AM -0500, Daniel Kahn Gillmor wrote: >> Alexey mentioned to me the other day that there might be an X.509v3 >> extension with the semantics "do not bother checking CRLs (or OCSP?) for >> this certificate" >> >> I looked for it, but i couldn't find it. Can someone identify it for >> me? > > He may be thinking of id-pkix-ocsp-nocheck, from RFC6960 (s4.2.2.2.1). That is used to avoid asking an OCSP responder about it's own certificate. I suspect Alexey was talking about id-ce-noRevAvail from RFC 3281: name id-ce-noRevAvail OID { id-ce 56 } syntax NULL (i.e. '0500'H is the DER encoding) criticality MUST be FALSE Russ From nobody Wed Nov 11 08:24:54 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678263A0F74 for ; Wed, 11 Nov 2020 08:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRIcayb39B70 for ; Wed, 11 Nov 2020 08:24:51 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552943A10E8 for ; Wed, 11 Nov 2020 08:24:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F1C48300AF1 for ; Wed, 11 Nov 2020 11:24:45 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L3M8h4-yFJdB for ; Wed, 11 Nov 2020 11:24:44 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id BA24E300A9E for ; Wed, 11 Nov 2020 11:24:44 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: <44D7BBDB-805E-45D5-B3F4-4758EDB282F9@vigilsec.com> Date: Wed, 11 Nov 2020 11:24:46 -0500 To: IETF LAMPS WG X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] Please give your feedback to NomCom X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:24:53 -0000 Please give your feedback to NomCom as requested below. Russ ---------------------------- NomCom is considering nominees for AD positions, IETF Chair, IAB, LLC = Board, and IETF Trust. We need more input from the community both on = specific nominees and on over-arching topics regarding what the = community wants from these specific groups and wants from its leadership = in general. We need *your* input. ** Deadline for community feedback is Friday November 20. ** We've paid attention to discussions on the ietf list. Issues raised = there have been brought up in interviews. We've also asked questions of nominees based on feedback received, and = based on the "Topics" that people said were important. We're listening to you.=20 But most of the input to date has come from a few consistently vocal = people. We need to hear from more of you. I scheduled our office hours during the 2 weeks before next week's IETF, = because IETF week is so busy. We have one more left (18:00-19:00 UTC = November 11). No-one but NomCom members showed up for our first 3. =E2=98=B9= If there is demand for more office hours, I'll schedule them; but this = really doesn't seem to be the preferred format for input. Most input is coming in as either=20 - email to nomcom20@ietf.org - feedback on https://datatracker.ietf.org/nomcom/2020/feedback/ On the feedback page, the specific nominees are all listed at the top. = General Topics are at the bottom. We pay attention to all the comments we get through these channels. I'll also try to hang out in Gather.Town during IETF breaks next week.=20= I'm not going to have a specific NomCom area in Gather.Town, because it = was really lonely hanging out there during IETF 108. But please feel free to hunt me down and bend my ear -- on NomCom issues = or just to chat. I miss seeing all of y'all! Barbara Barbara Stark NomCom 2020 Chair From nobody Wed Nov 11 19:57:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42983A1395 for ; Wed, 11 Nov 2020 19:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=BZBzdvdh; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=GXXEzl1j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZwOoDXKJDkd for ; Wed, 11 Nov 2020 19:57:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429183A1391 for ; Wed, 11 Nov 2020 19:57:42 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605153461; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=YcDBxLBYbz69/d/wTkl9VyY6pk3ysSiIZF2xw5YmX8Q=; b=BZBzdvdhHQvzHB7wjV2OSj38r6o8QWx0ikWBLhitlNvXonrQTBYLdxlJ7fmGFUqHqhBqB 3XwA3mCzdliW+c0DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605153461; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=YcDBxLBYbz69/d/wTkl9VyY6pk3ysSiIZF2xw5YmX8Q=; b=GXXEzl1jou9C6QNsEcMg5vPRadXCPIblzrWlsXFJxQNx6A9Qwf0QdYQGNFNQgPfkB9uTn TZh8olGyA71zZKlL3LXRtcZMyYON+CJvq+MSCc/xtO37pVgR6L+s+n8Wpns0OTzBzdppbmO OsqLasyBGPGu825L/lvAWMfI6unXoBdvDsuYW9Bp2it0DFzB2+rfrnOznMLof9WtD4Ld1NL Yi3btLLTWtlDRQJZqtk/Qx5xGVXUw/Zn6R9s/9AeEAit3MKI/61ywig0Ixz1jXiPni2xi6o SrKbykWTsS2S1+5Iym3xYqL+zpqGKy1RDqrJjeurrkNfEr/mVfROrNj1tauQ== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 98E7AF9A6; Wed, 11 Nov 2020 22:57:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 778BF20831; Wed, 11 Nov 2020 22:57:37 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , Matt Palmer , IETF LAMPS WG In-Reply-To: References: <87lff8gy20.fsf@fifthhorseman.net> <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 11 Nov 2020 22:57:36 -0500 Message-ID: <874klvgrbj.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 03:57:45 -0000 --=-=-= Content-Type: text/plain On Wed 2020-11-11 11:07:43 -0500, Russ Housley wrote: >> On Nov 11, 2020, at 3:36 AM, Matt Palmer wrote: >> >> He may be thinking of id-pkix-ocsp-nocheck, from RFC6960 (s4.2.2.2.1). > > That is used to avoid asking an OCSP responder about it's own certificate. Thanks for the suggestion, Matt! Russ, are you saying that it would be inappropriate to use it in a certificate that is not for an OCSP responder? The semantics do seem appropriate (as a non-critical extension) for these sample certs, as there will be no OCSP responder available. > I suspect Alexey was talking about id-ce-noRevAvail from RFC 3281: > > name id-ce-noRevAvail > OID { id-ce 56 } > syntax NULL (i.e. '0500'H is the DER encoding) > criticality MUST be FALSE looks like this was defined in "ITU-T Recommendation X.509: The Directory - Public-Key and Attribute Certificate Frameworks", the current version of which is at https://www.itu.int/rec/T-REC-X.509-201910-I/en, but paywalled. It looks like RFC 3281 (and its successor RFC 5755) both suggest that id-ce-noRevAvail is appropriate only for Attribute Certificates (ACs). But all three of these certs are Public Key Certificates (PKCs). That seems at least as inappropriate as applying id-pkix-ocsp-nocheck to a non-OCSP responder. Maybe i just want to include both extensions in each of the certs, since the semantics look right (there is neither a CRL endpoint nor an OCSP responder). So i'd just ignore the context of both of these pieces of documentation. Sound right? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6yysQAKCRDEDyVUMvKB Dz41AQCShy1mnOwQVn2u25eeCZezETAbt8MDRxiiFcOv4v07oQD+LZWrSH4e+O09 fE2ZFV6n6S/eX1i/FIEB+XKd6FdPfQQ= =SPCu -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 11 19:57:51 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413233A1391 for ; Wed, 11 Nov 2020 19:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=lRPZiUqK; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=TGVgLFy3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-NQUgD_s4O6 for ; Wed, 11 Nov 2020 19:57:43 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABE03A1392 for ; Wed, 11 Nov 2020 19:57:42 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605153461; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=g+CWM77/JsWoAY9IhpKJFIxlosPkFBnivg3VkhhX9Yc=; b=lRPZiUqK7BKrLasixmptowU0p6QtWsqAQwW9J+QQEsp6uKZDuYkyvhgNE5V9NwtM4AVhu eY6gTFl6N8lDOD6Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605153461; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=g+CWM77/JsWoAY9IhpKJFIxlosPkFBnivg3VkhhX9Yc=; b=TGVgLFy3vPtut31pcf6vMZlO9KlwzG01VPoYJ0/3wPMjFqK/n675cxlYNEQygmu+5MmKs +j/ebGci5+G1c7v6EEIuZzPEBwdGV6RK+PWoI9hOsNgFI+7K1ZaGnQX9/ZqotJZGPL77D2u EAcIQrpacj/AExv9reziHwxt0mhWt8G97STjSb5FqomMK5zYa7/kHCKauXB1L1ePUogFp3C nVrLW1lMLwX+yeagZmh918VbNUBZ6Rkr7/7StuUpNXgaqUq39IoRqlOOL99bxtqJpnWus5V XTb6qA/kTjxAQSSCYVBfrxvz9rDB7n+vejXHGrGpzcUdyPBeJ8R4gyllWPXg== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D32E6F9A7; Wed, 11 Nov 2020 22:57:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2A1A82040F; Wed, 11 Nov 2020 22:26:02 -0500 (EST) From: Daniel Kahn Gillmor To: Alexey Melnikov , LAMPS WG In-Reply-To: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> References: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 11 Nov 2020 22:26:01 -0500 Message-ID: <878sb7gss6.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Proposal to adopt "Guidance on End-to-End E-mail Security" (draft-dkg-lamps-e2e-mail-guidance-00) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 03:57:45 -0000 --=-=-= Content-Type: text/plain On Tue 2020-11-10 18:20:43 +0000, Alexey Melnikov wrote: > I would like to propose that this document > [draft-dkg-lamps-e2e-mail-guidance] to be adopted by LAMPS. It will be > a dependency for the Header Protection draft and I think 2 drafts have > complementary scopes. Thanks Alexey. I'm glad you find it useful. As the initial author of the draft, i'd be happy to have it put under the aegis of the WG, and i think it's definitely relevant here. I also volunteer to be the editor of it if it's adopted, and am willing to shape it according to the consensus of the WG. Most importantly, i'd love to get more feedback from other implementers about the current context (and also, please let me know what it's missing). I've been continuing to update it in revision control at https://gitlab.com/dkg/e2e-mail-guidance but of course i haven't published it during the current enforced downtime for datatracker submissions. If there's a different place that LAMPS folks would prefer to follow revision controlled development, let me know. i can of course mirror git in multiple places, but i'd prefer to have to only keep track of one issue tracker and one queue of merge/pull requests. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX6yrSQAKCRDEDyVUMvKB D1JzAQDduC89kAYLQ8xhM3HhiHYIwPSlfaeEMwxyDDDFaHTbjQD6AttW4rb5TKsM jw4PsDoabJR0lRApVZTfCgAOo/YgDwI= =6YNv -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 06:55:35 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5611D3A1170 for ; Thu, 12 Nov 2020 06:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wxmJl-18NJm for ; Thu, 12 Nov 2020 06:55:32 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB553A116C for ; Thu, 12 Nov 2020 06:55:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 77742300BB6 for ; Thu, 12 Nov 2020 09:55:29 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5uBd6Siw9_4p for ; Thu, 12 Nov 2020 09:55:27 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id CFEDB300A9E; Thu, 12 Nov 2020 09:55:26 -0500 (EST) From: Russ Housley Message-Id: <4F4638CC-090D-4530-90D1-674A91204ADD@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1D89E8D2-7C22-400A-9F4D-555612D61A6F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 12 Nov 2020 09:55:27 -0500 In-Reply-To: <874klvgrbj.fsf@fifthhorseman.net> Cc: Matt Palmer , IETF LAMPS WG To: Daniel Kahn Gillmor References: <87lff8gy20.fsf@fifthhorseman.net> <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> <874klvgrbj.fsf@fifthhorseman.net> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 14:55:34 -0000 --Apple-Mail=_1D89E8D2-7C22-400A-9F4D-555612D61A6F Content-Type: multipart/alternative; boundary="Apple-Mail=_279A5477-6788-4D4A-A82E-423B1150C499" --Apple-Mail=_279A5477-6788-4D4A-A82E-423B1150C499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 11, 2020, at 10:57 PM, Daniel Kahn Gillmor = wrote: >=20 > On Wed 2020-11-11 11:07:43 -0500, Russ Housley wrote: >>> On Nov 11, 2020, at 3:36 AM, Matt Palmer = wrote: >>>=20 >>> He may be thinking of id-pkix-ocsp-nocheck, from RFC6960 = (s4.2.2.2.1). >>=20 >> That is used to avoid asking an OCSP responder about it's own = certificate. >=20 > Thanks for the suggestion, Matt! >=20 > Russ, are you saying that it would be inappropriate to use it in a > certificate that is not for an OCSP responder? The semantics do seem > appropriate (as a non-critical extension) for these sample certs, as > there will be no OCSP responder available. Correct, but it does not say that no CRL is available. >=20 >> I suspect Alexey was talking about id-ce-noRevAvail from RFC 3281: >>=20 >> name id-ce-noRevAvail >> OID { id-ce 56 } >> syntax NULL (i.e. '0500'H is the DER encoding) >> criticality MUST be FALSE >=20 > looks like this was defined in "ITU-T Recommendation X.509: The > Directory - Public-Key and Attribute Certificate Frameworks", the > current version of which is at > https://www.itu.int/rec/T-REC-X.509-201910-I/en, but paywalled. You are right, it is for attribute certificates. X.509 says: This extension shall not be included in public-key = certificates or in attribute certificates issued to AAs. > It looks like RFC 3281 (and its successor RFC 5755) both suggest that > id-ce-noRevAvail is appropriate only for Attribute Certificates (ACs). > But all three of these certs are Public Key Certificates (PKCs). That > seems at least as inappropriate as applying id-pkix-ocsp-nocheck to a > non-OCSP responder. >=20 > Maybe i just want to include both extensions in each of the certs, = since > the semantics look right (there is neither a CRL endpoint nor an OCSP > responder). So i'd just ignore the context of both of these pieces of > documentation. >=20 > Sound right? We do not seems to have an extension equivalent to id-ce-noRevAvail for = public-key certificates. With the move toward short lived public-key = certificates, we should probably work with ITU-T to allow its use in any = certificate. Russ --Apple-Mail=_279A5477-6788-4D4A-A82E-423B1150C499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Nov 11, 2020, at 10:57 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

On = Wed 2020-11-11 11:07:43 -0500, Russ Housley wrote:
On Nov 11, 2020, at 3:36 AM, Matt Palmer <mpalmer@hezmatt.org>= wrote:

He may be thinking of = id-pkix-ocsp-nocheck, from RFC6960 (s4.2.2.2.1).

That is used to avoid asking an = OCSP responder about it's own certificate.

Thanks for the suggestion, Matt!

Russ, are you saying that it would be inappropriate to use it = in a
certificate that is not for an OCSP responder? =  The semantics do seem
appropriate (as a non-critical = extension) for these sample certs, as
there will be no = OCSP responder available.

Correct, but it does not say that no CRL is = available.


I suspect Alexey was talking about = id-ce-noRevAvail from RFC 3281:

=      name =           id-ce-noRevAva= il
     OID =            { = id-ce 56 }
     syntax =         NULL (i.e. '0500'H is = the DER encoding)
=      criticality    MUST be = FALSE

looks like this was = defined in "ITU-T Recommendation X.509: The
Directory - = Public-Key and Attribute Certificate Frameworks", the
current version of which is at
https://www.itu.int/rec/T-REC-X.509-201910-I/en, but = paywalled.

You are right, it is for attribute = certificates.

X.509 says:  This extension shall not be = included in public-key certificates or in attribute certificates issued to = AAs. 
   
It looks like RFC 3281 (and its successor RFC 5755) both = suggest that
id-ce-noRevAvail is appropriate only for = Attribute Certificates (ACs).
But all three of these certs = are Public Key Certificates (PKCs).  That
seems at = least as inappropriate as applying id-pkix-ocsp-nocheck to a
non-OCSP responder.

Maybe i just = want to include both extensions in each of the certs, since
the semantics look right (there is neither a CRL endpoint nor = an OCSP
responder).  So i'd just ignore the context = of both of these pieces of
documentation.

Sound right?

We do not seems to have an extension equivalent to = id-ce-noRevAvail for public-key certificates.  With the move toward = short lived  public-key certificates, we should probably work = with ITU-T to allow its use in any certificate.

Russ

= --Apple-Mail=_279A5477-6788-4D4A-A82E-423B1150C499-- --Apple-Mail=_1D89E8D2-7C22-400A-9F4D-555612D61A6F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCX61M3wAKCRCK5O7Q9ZwR y8BlAKCRN5vt0FFuhhdyf/RCy64GPu7flwCgmpR7A1yUtVkTCf9dRC/SkKvoVVM= =RqSx -----END PGP SIGNATURE----- --Apple-Mail=_1D89E8D2-7C22-400A-9F4D-555612D61A6F-- From nobody Thu Nov 12 07:24:08 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB41E3A11E3 for ; Thu, 12 Nov 2020 07:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVNFNDxr5UY4 for ; Thu, 12 Nov 2020 07:24:05 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0A73A11D3 for ; Thu, 12 Nov 2020 07:24:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8C0CB300B0F for ; Thu, 12 Nov 2020 10:24:02 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iBHz2IRBbEPk for ; Thu, 12 Nov 2020 10:24:00 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 27BAB300BA2; Thu, 12 Nov 2020 10:24:00 -0500 (EST) From: Russ Housley Message-Id: <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78A812BD-47B1-4C9B-AD61-239FCB1B6BDD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 12 Nov 2020 10:24:01 -0500 In-Reply-To: <000701d64d1f$7a7cea20$6f76be60$@x500.eu> Cc: LAMPS To: Erik Andersen References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 15:24:07 -0000 --Apple-Mail=_78A812BD-47B1-4C9B-AD61-239FCB1B6BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Erik: X.509 defines the id-ce-noRevAvail extension. It was first referenced = by RFC 3281 for use in attribute certificates, > name id-ce-noRevAvail > OID { id-ce 56 } > syntax NULL (i.e. '0500'H is the DER encoding) > criticality MUST be FALSE X.509 says: This extension shall not be included in public-key = certificates or in attribute certificates issued to AAs.=20 We do not seems to have an extension equivalent to id-ce-noRevAvail for = public-key certificates. With the move toward short lived public-key certificates, especially = with the work in the IETF ACME WG, I wonder if X.509 can be changed to = allow this extension to appear in end-entity public-key certificates. Russ --Apple-Mail=_78A812BD-47B1-4C9B-AD61-239FCB1B6BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Erik:

X.509 defines the id-ce-noRevAvail extension.  It = was first referenced by RFC 3281 for use in attribute = certificates,

     name =           id-ce-noRevAva= il
     OID =            { = id-ce 56 }
     syntax =         NULL (i.e. '0500'H is = the DER encoding)
     criticality =    MUST be FALSE

X.509 = says:  This extension shall = not be included in public-key certificates or in attribute certificates = issued to AAs. 

We do not seems to have an extension = equivalent to id-ce-noRevAvail for public-key certificates.

With the move toward = short lived public-key certificates, especially with the work in the = IETF ACME WG, I wonder if X.509 can be changed to allow this extension = to appear in end-entity public-key certificates.

Russ

= --Apple-Mail=_78A812BD-47B1-4C9B-AD61-239FCB1B6BDD-- From nobody Thu Nov 12 12:47:16 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4633A0820 for ; Thu, 12 Nov 2020 12:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rncPODwgJfj3 for ; Thu, 12 Nov 2020 12:47:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E763A082F for ; Thu, 12 Nov 2020 12:47:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EEFF1389D0; Thu, 12 Nov 2020 15:47:45 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UDKmDaDOSADK; Thu, 12 Nov 2020 15:47:45 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 827A9389C4; Thu, 12 Nov 2020 15:47:45 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3C43AAB5; Thu, 12 Nov 2020 15:47:11 -0500 (EST) From: Michael Richardson To: Russ Housley cc: Erik Andersen , LAMPS In-Reply-To: <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 20:47:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > X.509 defines the id-ce-noRevAvail extension. It was first referenced > by RFC 3281 for use in attribute certificates, I looked up the meaning: The noRevAvail extension, defined in [X.509-2000], allows an AC issuer to indicate that no revocation information will be made available for this AC. >> name id-ce-noRevAvail >> OID { id-ce 56 } >> syntax NULL (i.e. '0500'H is the DER encoding) >> criticality MUST be FALSE > X.509 says: This extension shall not be included in public-key > certificates or in attribute certificates issued to AAs. > We do not seems to have an extension equivalent to id-ce-noRevAvail f= or public-key certificates. > With the move toward short lived public-key certificates, especially > with the work in the IETF ACME WG, I wonder if X.509 can be changed to > allow this extension to appear in end-entity public-key certificates. It seems like a good thing. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+tn04ACgkQgItw+93Q 3WVuHgf+NlAk3lQZTumB2V6KAqz9YLK870+1GK8CzmTxg3rpCMY9Hus1SLNKZ3Jz wEVKLtEMVY/kc0M6EIA1z4LO0p7VbJkwvCYFeOkll3XwMniDXCDYJCqN29EuxNnR 9/6qDR/b2yky04IQ756cRNDJC5RsYTuS0+/IqXymulb+YkH3aqKKFjuWSGZV82mx BApA9L7NAHCP4GGe/wvwR4FCDKoyEtpOkFAArDorRAzAmQdlrQ7rUuuFRALTkaWx HkHFlfJoJUQQm1AFoKX+H7BV6AgI29vrDmvXHrcgrx+gLgtTd8zktrmxaBBwMQuA UeAWwHoL0Rnr17zfEy+oq6Q88rYRAA== =QJgc -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 13:00:44 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6C93A0880 for ; Thu, 12 Nov 2020 13:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yy_cK7vZ6aYZ for ; Thu, 12 Nov 2020 13:00:41 -0800 (PST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 118D53A0879 for ; Thu, 12 Nov 2020 13:00:41 -0800 (PST) Received: by mail-pf1-f169.google.com with SMTP id c20so5673568pfr.8 for ; Thu, 12 Nov 2020 13:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z9fEr8ZlIiUvXWmgXRbGcBPpb99xPnUlRgYMW2dn+Sk=; b=t/ZTo4n4z32mU7x7mSMe+McKxUHP6arOtL25LTcDhZ6qQPdYB1Jj6btIstnmhAZI0D dRs42Tm4ceLhx6WH2lkm6Vxistt2Fzk/jJArn8JlsZ0hyR8LWnICWbqj9wR/Jv2PR045 JfEbtJCK7F9FWQJg1N6ezrRemRckm/h6I/RF+r17HMVGDpbIDi3geHkboqxWdDgVoHw0 tbDVa7a/fJAhM6nt+G4FH39fcSLRUJCPXHBbGs3my8bMWNG1T9kVtk+Jb9wTjC9P/rKt OzhqE1yUfLe2lSVMo0nJnXCBzenQpNEvc+mpuibYvkUGW3Mk/UKtXA90IQs/MnxUCOSP nrIg== X-Gm-Message-State: AOAM530tZl+/RxsiE0wFdXGZ4MTlVHjD7lcI8sN3CHADxQNuf1j+VBeB HVZJAgR3WMlPb+xEbkHAhb73mJi0GVY= X-Google-Smtp-Source: ABdhPJwxJYZ1k43DnQRP2ioJAIiZbdzTwqiteJXwPnmAzR+Jm4Pbm3ZN/hMZNn9VjxS2vsWQY5oYLA== X-Received: by 2002:a63:ec50:: with SMTP id r16mr1087842pgj.281.1605214840254; Thu, 12 Nov 2020 13:00:40 -0800 (PST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com. [209.85.210.179]) by smtp.gmail.com with ESMTPSA id q12sm7657338pfc.84.2020.11.12.13.00.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 13:00:40 -0800 (PST) Received: by mail-pf1-f179.google.com with SMTP id c66so5688828pfa.4 for ; Thu, 12 Nov 2020 13:00:40 -0800 (PST) X-Received: by 2002:a17:90b:1b52:: with SMTP id nv18mr1164515pjb.172.1605214839932; Thu, 12 Nov 2020 13:00:39 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> In-Reply-To: <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> From: Ryan Sleevi Date: Thu, 12 Nov 2020 16:00:29 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Erik Andersen , LAMPS Content-Type: multipart/alternative; boundary="000000000000528fc005b3ef34b4" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:00:43 -0000 --000000000000528fc005b3ef34b4 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 12, 2020 at 10:24 AM Russ Housley wrote: > We do not seems to have an extension equivalent to id-ce-noRevAvail for > public-key certificates. > > With the move toward short lived public-key certificates, especially with > the work in the IETF ACME WG, I wonder if X.509 can be changed to allow > this extension to appear in end-entity public-key certificates. > Under what processing model would such an extension be relevant for PKCs? When a local client is configured to use an alternative source of revocation (such as a locally-configured LDAP directory)? It's not immediately obvious the value proposition of "affirmatively asserting no" vs the status quo of "definitively not asserting any information source", and under what processing model a client would find it useful or important to distinguish these cases. --000000000000528fc005b3ef34b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 12, 2020 at 10:24 AM Russ= Housley <housley@vigilsec.com> wrote:


<= /div> --000000000000528fc005b3ef34b4-- From nobody Thu Nov 12 13:44:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDEB3A1080 for ; Thu, 12 Nov 2020 13:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyEMabwfIK8l for ; Thu, 12 Nov 2020 13:44:18 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE293A0E92 for ; Thu, 12 Nov 2020 13:44:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 898C1300BB9 for ; Thu, 12 Nov 2020 16:44:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OJbJBV-tmeKU for ; Thu, 12 Nov 2020 16:44:06 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 761A4300A87; Thu, 12 Nov 2020 16:44:06 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8531092B-D21D-442B-AC05-44C5FBAE104E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 12 Nov 2020 16:44:07 -0500 In-Reply-To: Cc: LAMPS , Erik Andersen To: Ryan Sleevi References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:44:25 -0000 --Apple-Mail=_8531092B-D21D-442B-AC05-44C5FBAE104E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ryan: > On Thu, Nov 12, 2020 at 10:24 AM Russ Housley > wrote: > We do not seems to have an extension equivalent to id-ce-noRevAvail = for public-key certificates. >=20 > With the move toward short lived public-key certificates, especially = with the work in the IETF ACME WG, I wonder if X.509 can be changed to = allow this extension to appear in end-entity public-key certificates. >=20 > Under what processing model would such an extension be relevant for = PKCs? When a local client is configured to use an alternative source of = revocation (such as a locally-configured LDAP directory)? When an end-entity has a very short lifetime, the certificate will be = expired before all of the steps can be performed to revoke it. As you = know, it takes time for the compromise to be discovered, reported, and = the certificate is actually revoked. > It's not immediately obvious the value proposition of "affirmatively = asserting no" vs the status quo of "definitively not asserting any = information source", and under what processing model a client would find = it useful or important to distinguish these cases. The difference is the processing time it takes for the RP to try to find = information when the CA knows in advance that there never will be any. Russ --Apple-Mail=_8531092B-D21D-442B-AC05-44C5FBAE104E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ryan:

On Thu, Nov 12, 2020 at 10:24 AM Russ Housley <housley@vigilsec.com> wrote:
We do not seems to have an extension = equivalent to id-ce-noRevAvail for public-key certificates.

With the move toward = short lived public-key certificates, especially with the work in the = IETF ACME WG, I wonder if X.509 can be changed to allow this extension = to appear in end-entity public-key = certificates.

Under what processing = model would such an extension be relevant for PKCs? When a local client = is configured to use an alternative source of revocation (such as a = locally-configured LDAP = directory)?

When = an end-entity has a very short lifetime, the certificate will be expired = before all of the steps can be performed to revoke it.  As you = know, it takes time for the compromise to be discovered, reported, and = the certificate is actually revoked.

It's not immediately obvious the = value proposition of "affirmatively asserting no" vs the status quo of = "definitively not asserting any information source", and under what = processing model a client would find it useful or important to = distinguish these cases.

The difference is the processing time it takes for the = RP to try to find information when the CA knows in advance that there = never will be any.

Russ

= --Apple-Mail=_8531092B-D21D-442B-AC05-44C5FBAE104E-- From nobody Thu Nov 12 13:51:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5643A09C5 for ; Thu, 12 Nov 2020 13:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=Qb0tnugV; dkim=pass (1024-bit key) header.d=digicert.com header.b=wVIrsDq+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pbbxf3_FNSi for ; Thu, 12 Nov 2020 13:51:19 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896B33A0997 for ; Thu, 12 Nov 2020 13:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1605217878; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=OEm+SL5Tav7hKPXfzegmyjfk+CC+lQb4L7+7Cak3xmA=; b=Qb0tnugV+MKC0qzEHyr93RE+uVH1sg6CyeReEXUehkaKMgP36xOH49Ps3dNNVOA2LqpZH5 eMJdLg0z0NEOAGrokFzSq28sqNJIX/kDZRaTXxwA9w+O+K/4ghSFGsriOH1M0AD6b99YCb GoHp0ExrjAQCrUWt88WzCSHRBXq1fS0= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-84-Ir5ILTtKPByZUq_NvN8WNQ-1; Thu, 12 Nov 2020 16:51:13 -0500 X-MC-Unique: Ir5ILTtKPByZUq_NvN8WNQ-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nzEc2RRIhrNue7PQZTczGcx/h/DSMJBjChikuWB/6Gu2KKCUhdWWYoqTVSkDlbV6BImQfy4ZhSsiLf12OCXoXjZZkvvH8UquqQVLrN6QspoEAfZU5aJwou0NoQnQhQv206vGCoEFd4fVgft2iPDVOxJvuQ60kgKeLwrqkG5V2v3Vn5HyX2wWgpQmpzU9c3axqPL3VY7hd82o5qJEO8KBtCBQKkvb5ZOWOlguVBTvgg6/LhwwRtbTNNRqnho/+wi9vk4uhwT6wmpom8t1IgiROJonNrdSIZO7I9a/vHVoLk9+fHZ6r0vBerCTSQ7bPPiLyvpSJ2JH2VVUgIPm6EzzDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OEm+SL5Tav7hKPXfzegmyjfk+CC+lQb4L7+7Cak3xmA=; b=fajcIHflA6e9wpBmNHJ2cIvoQ4OPOfGhsakb/kkpRmIu/28W3qdpJdnV0gnWo+fZRRm/Vtwzo4FEZk0xsS1oywgq6+/tjrOr1IpVzFLVGU9NtkwBCh9vJEup9bARy85XMIL09LBneR1drGY0Pm26XcMDXe71xN+DQ/e/RAcSfb+QxBm/XNFOuNxuetlSBlb5D1HIyIwfF8GZ4hiSGS7jt2t1NSulO+1YcfOYjGiEyRcJ+xnktoCU3ueJOZbVZaXruLPCLSHXsPfJQ+5N58I28h6bxB/0suyZ+BKF9qSUYbpm/9Dkn2k0oWfT21iFGkpoROarpH/U046KzszJp4nCqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OEm+SL5Tav7hKPXfzegmyjfk+CC+lQb4L7+7Cak3xmA=; b=wVIrsDq+n8/3kQA1lTcYZnRCMN0dVCgix6N193pJuFc/aRyXQXtjyNx6iDHiAKSM/ZzqgkFzRBURodS8ydEjvg5V9oyQ8wxwDqUGGzoMydk/ykp4A6ZNtX6o1bb4WXPSgsZEfTNkrp9PceIKLWlz/6MvBvgE3p2X0/Bb9LxyPa4= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB3151.namprd14.prod.outlook.com (2603:10b6:208:12c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 21:51:10 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::1825:d234:ae38:46a2]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::1825:d234:ae38:46a2%7]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 21:51:10 +0000 From: Tim Hollebeek To: LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNw== Date: Thu, 12 Nov 2020 21:51:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=digicert.com; x-originating-ip: [96.236.215.247] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9453459-55ab-4809-ff46-08d88755115b x-ms-traffictypediagnostic: MN2PR14MB3151: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dV3O6S6amrUFMb9MuGv3Bar8fA8tmFx0nUVrPgbVsUZ0X9Vh03ldFzQfxYXE3QS1Z9AkFyFGG3+dXdVNJjBQNbJuRqzPFoTtYffkxccf4cmJ0H+TbYCao7HRKnQGYgi/vX7hj1MyontJ8036lEQ0EYTOjyW95OJeZ7J3m2wAIGgAQTzPrrw8UZc0Rey4eoBwRO/7X6Re07rjSXFVuMw45j4jkXu6dZzcXBHzcnJGVn5bt4ScV7diq+cx6vCxKL207ImJ491N4IaZqVCcNHxnIvj5aPFsUCeG1drkamQ/h/46FCu/hWL5/M50/NiedDYnBqiVnwBjxTtBhVraVYjvE7ebd1DXP6Bq/vI3Sga3hesnUuoqoiSSGd67HWxhvKdAyfzUePNKr3Ufs4lTRTdSIA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(39860400002)(346002)(396003)(186003)(5660300002)(66446008)(9686003)(99936003)(8676002)(55016002)(26005)(33656002)(478600001)(66946007)(66616009)(66556008)(86362001)(52536014)(71200400001)(64756008)(7696005)(44832011)(6506007)(76116006)(166002)(8936002)(2906002)(6916009)(66476007)(966005)(316002)(4744005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: qCkGg3ltNoBurY8+Fpx6B0sWE0Y0UvYfFP2tEeRw+YNism0Yd/GSAR5x15dNpy11I66ynXQOf7yPC12emQbBOReJz12LULfGKa30P2Jgk/cnaS/JCbdC52AlFT7Nx4ScpfGLw2ZgBuwK3PxNGMyHJ28kopYbC6F2w5ryksafWEtbrp45ar2WZyWr8AShX/8C3ALaRAGeavk7bIyI/rXQAm5gBx4KoOwhbNhCYCIyFS++A543j8Mm25Ktk+vqNd6J8rIBdn9A0nwN7d/xwNLr4VueMyFl3cncQFbvzWRen/2Gq8hC1+ga+zrFqXsxYKJqcCZXd3IKM5rKa19XWHit8nzw/ubElV7SV70n4+Fu/H4TZ0QB/h05vohLlOtYFP9FwMcw/6PILpoXHlHJ7iFoB74N85R1llOvsnT4N3PJ0liuV77v4MROZkEIwP+7PYUisoE6/Rr28mpZtYXdU2WAkIOvK5qZMsPFsqDod4SLGqjQMSyCJCAp1HgxG2MJPMPG7yro5TaS/BmYa37B1nTmHZiZkBPy2anO4n1++xTR/QsgnFxfDbXTVOeI9xt9OUvOsWR4kdE4HVbnWoHOpTgIOnsH3mmn61y4P96MXJ10/hfZ0q8Aslo4FF5FyM1L4HYlx+VR23unqJ8MO0lVhwohpNO4J6xsdZWzaMK68ANLJlSX7KmCnB9buHfc8zG/4hJpNgBGh+mc3WSbiOqHXyP1zhhafQp4s9pB89w6KxV3IidYfzGWLyxTJXTE/0xZmXIJs0fAA/3udlr3/QOHMFIsjt1q+Gj3b3mmrRizsZH6nD2cnsUWnj65AO8FEB7CnFhOMKraZ8N49KhrOB1mPhEi84FnwP2Rw3u7JlNZAPzcy6r0pVkDxnviKnBKmS60FR1p7pONpGJdfp6f/d+OaMrZuA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00B3_01D6B914.05468340" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9453459-55ab-4809-ff46-08d88755115b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 21:51:10.5087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbdVs+vRRsTOPIYsYQw895Zm9K1zhOUr5OzrUxJpTv2IUe+9fMhO/nj/axoTlv0IaJKMwcy5UYb4qKbH+RfxxLbyecqG+N4cnFvi3K1VZcM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3151 Archived-At: Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 21:51:21 -0000 ------=_NextPart_000_00B3_01D6B914.05468340 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00B4_01D6B914.05468340" ------=_NextPart_001_00B4_01D6B914.05468340 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For those of you who are following the discussion, you're probably aware of the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use within CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt Please indicate by November 25th whether you support adoption of draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim ------=_NextPart_001_00B4_01D6B914.05468340 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those of you who are = following the discussion, you’re probably aware of the following = brief draft that is related to the CMP work.

It allocates an OID for AES-GMAC, and contains = provisions for its use within CMS.  The draft is available = here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-ma= c-alg-00.txt

 

Please = indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

 

-Tim

 

------=_NextPart_001_00B4_01D6B914.05468340-- ------=_NextPart_000_00B3_01D6B914.05468340 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAxMTEyMjE1MTA5WjAvBgkqhkiG9w0BCQQxIgQgmGsuRngSRWqTJ+75SAgmrc2D/sMa TOWmVdH8rg+WEGMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAJ2JonxIccbIJ2/RfGkX+AEjeOZgZ4qlBrY/43NebgYRJhnweqdJN6dam3laMaPHYb/LVyGn dSyXo1LrnE1rMt63DtZBhEjGwZ6BMerxVHY72uF8TGaMhiW+SJj55hv3xceST6yY6hD+9VYrd9C5 qylMAoOnb3cqcx6jVqD5BJ+5knZKBlf5L7AOwuX0k8+jANY3Hx1ES4CrZ5TvohLeaLk72x+oaqux z+VuIkfTLoxwyHadNVe2ar8GAsx7YmU2Lw8jspzMSipkdBePUrZBeEIXO/CJSigznMla/QvOyZd9 jceE7AG9f8Asq8XHbvzTObPwj1ITVlkuGDi6CLRX85QAAAAAAAA= ------=_NextPart_000_00B3_01D6B914.05468340-- From nobody Thu Nov 12 14:03:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58683A0E68 for ; Thu, 12 Nov 2020 14:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un1ZjEYZUREc for ; Thu, 12 Nov 2020 14:03:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7843A0E47 for ; Thu, 12 Nov 2020 14:03:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C5D1E389BC; Thu, 12 Nov 2020 17:04:18 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hVqdeZmFLjt1; Thu, 12 Nov 2020 17:04:18 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C936389B3; Thu, 12 Nov 2020 17:04:18 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D9B32D2C; Thu, 12 Nov 2020 17:03:43 -0500 (EST) From: Michael Richardson To: LAMPS , Erik Andersen In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 22:03:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: >> It's not immediately obvious the value proposition of "affirmatively >> asserting no" vs the status quo of "definitively not asserting any >> information source", and under what processing model a client would = find >> it useful or important to distinguish these cases. > The difference is the processing time it takes for the RP to try to > find information when the CA knows in advance that there never will be > any. It also has bearing to the EAP-TLS discussion in EMU about wither to OCSP(staple) or not for industrial situations. The RPs in question are EAP clients which do not have any connectivity (yet) with which to attempt to find info. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+tsT8ACgkQgItw+93Q 3WV/zwf/f9aat6eaJSgFAjbVaNKTueiRL2kHeZXhfkFPfo78p05o/kptu45OQ+Rx 9AKyP78956TRqs4+B6BBT+cW3H+YwUAo9G2qsfwm/N8aggGoPkoNJRTa0h0rxLUM iwUiLoLyoB99VhdNzQi2+mtRFNIDOeXS04pHvzYZqU8rBph8mV1Dx49eUjY8Yd6l hwMpNis5EJ9dvKUbq8Sf/IMAajpTvxBRY8aWBjrLGMPfv20U8DvYKNTVQnwMe21Z E0+OgSAMT3XEL8Eo0tU01QLq26zfxyUxdeEGCXD4HOIBRn6vFaP+77dJNiXVAHLN pX/dnmCZIUSuWnkhJilXeKax0vNj9w== =V5pW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 14:10:13 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08873A0E56 for ; Thu, 12 Nov 2020 14:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67zOgXIRFNdc for ; Thu, 12 Nov 2020 14:10:10 -0800 (PST) Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) (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 C4DC43A0E5B for ; Thu, 12 Nov 2020 14:10:10 -0800 (PST) Received: by mail-pg1-f174.google.com with SMTP id 62so5373672pgg.12 for ; Thu, 12 Nov 2020 14:10:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PZjTtaFPjqonRHx5gd/Cxffg10dPaH3cXqLPwsIeG30=; b=gGr/TcF5tIKBl51hJNaGnOS5BlhKPXT6EzQk0Z+4YOwx7shBXbc5z4GyYikQR6IyYh qX5gzvgjCNMvhQz2iRN5OcGvZC+FLlKagluX8SiUpBrjG36FMp5NJPsebdlPCBKAByLr ZAbGHZ7e0YXsJ6FxQRM29f6d4qOMoC8HrrKYudfFjX3sMpFH/A0dJpp4OyML4iVeLA+5 WswdsqviAm5kf6oOeRIko+MMyXQqIxWfJJ5KIQtW/Hr8Dw4Lz5aWtW0L9iU4LrzC3oFv 5wTOE8n2ssYrOQejnsyZIjkZRv278WrbwBApwFwDHAy53g1FGeR/30N2vcPYKw0IVAYe /uHw== X-Gm-Message-State: AOAM5317mdZ/tI0oYquXeX7LUkp45SR48mvsXuUvR5jpumjjJrNBfKH+ n490NszO+QfocprKeNacLITdSpFjnx4= X-Google-Smtp-Source: ABdhPJxueQRqw+izp8xWobcHTmClRRm9fBuDZwRwROePiB0MFfuf8FZofcelX0q3kSBkfrtexBBcaw== X-Received: by 2002:a05:6a00:212b:b029:18b:ad77:1a27 with SMTP id n11-20020a056a00212bb029018bad771a27mr1454111pfj.40.1605219009895; Thu, 12 Nov 2020 14:10:09 -0800 (PST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com. [209.85.215.170]) by smtp.gmail.com with ESMTPSA id g18sm7481543pfu.131.2020.11.12.14.10.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 14:10:09 -0800 (PST) Received: by mail-pg1-f170.google.com with SMTP id i26so5397662pgl.5 for ; Thu, 12 Nov 2020 14:10:09 -0800 (PST) X-Received: by 2002:a17:90b:3884:: with SMTP id mu4mr1315897pjb.202.1605219009585; Thu, 12 Nov 2020 14:10:09 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Thu, 12 Nov 2020 17:09:58 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Ryan Sleevi , LAMPS , Erik Andersen Content-Type: multipart/alternative; boundary="000000000000da673a05b3f02c22" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 22:10:12 -0000 --000000000000da673a05b3f02c22 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 12, 2020 at 4:44 PM Russ Housley wrote: > It's not immediately obvious the value proposition of "affirmatively > asserting no" vs the status quo of "definitively not asserting any > information source", and under what processing model a client would find it > useful or important to distinguish these cases. > > > The difference is the processing time it takes for the RP to try to find > information when the CA knows in advance that there never will be any. > I'm sorry, I think you answered a different question than I was asking, so I'll try to rephrase it using your response. I'm not asking about "why would you use shortlived certificates", I'm trying to understand what you see as the steps the RP takes to "try to find information", if no references to such information are made available to the RP within the certificate. Concretely: If a certificate lacks OCSP or CRLs in-band, where is it going to find the information? Is the assumption that the client will be performing LDAP directory checks based on the DN of the cert, as envisaged in X.509v1? Is the assumption that the client is locally configured to support some local configuration that points to a repository with revocation? In order for there to be steps that are skipped, there needs to be a statement of what steps are performed. We can "obviously" disable CRLs and OCSP by simply not providing such information in the certificate, so I was hoping you could articulate what other sources of information that might be used by a client where such an affirmative expression would be relevant and necessary. --000000000000da673a05b3f02c22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Is the assumption that the client is locally configured to support some = local configuration that points to a repository with revocation?
--000000000000da673a05b3f02c22-- From nobody Thu Nov 12 14:10:24 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBB93A0E5B for ; Thu, 12 Nov 2020 14:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bB_3nkVQGSjw for ; Thu, 12 Nov 2020 14:10:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F113A0E5A for ; Thu, 12 Nov 2020 14:10:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E006389C7; Thu, 12 Nov 2020 17:10:54 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id H155Z4o7b6XU; Thu, 12 Nov 2020 17:10:53 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BDDE2389C5; Thu, 12 Nov 2020 17:10:53 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 42705D2C; Thu, 12 Nov 2020 17:10:19 -0500 (EST) From: Michael Richardson To: Tim Hollebeek cc: LAMPS In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 22:10:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tim Hollebeek wrote: > https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-0= 0.txt > Please indicate by November 25th whether you support adoption of > draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. Seems short and to the point. An example message in an appendix would be nice. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+tsssACgkQgItw+93Q 3WWTSAf/apPgVQYhmXOTInV6GGWEYvRcmq0r/t6VEgaqFgc5ZKIo90YgI0d0sLEA 6BKAnj4xbiFW7+FklRfcH3RueMqOAFEhL38MoUH9QVbXTov2GQpAfcAGlY/fzt6m QDYVAY+5JEgZpB3IsDZLtE2ljsh3uGfCyyhj1/HrCairxwr/JdhLD4eRIRUzecr7 mTYxK1kr4evqWypDPCGwEZVziucWr0OT94pJJ88zmGQalUCqsVdfsmotyBJIImPo CL/8oyyRaLI/zqPudmAGwQz048ZzBZgOvwyDm3+7xNFN2Y4LDqg3cWdtJ/q5cQXd tdDR1vjilePEtWAAwNMxyfvJm1gdqg== =i8Fj -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 14:11:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBDB3A0E68 for ; Thu, 12 Nov 2020 14:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GRs9BGCEuEf for ; Thu, 12 Nov 2020 14:11:37 -0800 (PST) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 9F2153A0E5A for ; Thu, 12 Nov 2020 14:11:37 -0800 (PST) Received: by mail-pf1-f181.google.com with SMTP id 10so5840912pfp.5 for ; Thu, 12 Nov 2020 14:11:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jFvq7mJnnPp0waPv3JPh+vajHkW+xr7vlxTbSLzBrk4=; b=k7RvZb6yrCcRIbhOU5my50jViMzmq3SJipcWP9TxWrtfnCkyeQ/fJqiKENKW3Fttep 78gJ8QjAbm7fsZxjguS19uYGyY4kIIPkmcv2KU6eaAmGhZt/SqgS9ZpH7pkHP2FyTZar WpdD+Ej0fqbUvOTCR+2H47nMg8nZIbzEDe4b2caGVad1cPjYx0cGvGT0az0oBDijrYsk JqGqJeov+z7eEADHaZGRQWDgIsuV4u3rKsTpvsuUkvgVN1A6klJZVBcM9YNzxia0eUCx MyeB0CwXha4QJjk1WNOz+yIKCjjqReVw6sQqS/SWuHhbwzwOOSlnuJ3T0ComaLKLgqiq 3/5g== X-Gm-Message-State: AOAM531eQPiGEymilV1dH8SN5MU0oZwRURQn2tOtup5700XQEXw8+jqm RlWKRUkd6GzdPNHtZsWhZTy500hTSek= X-Google-Smtp-Source: ABdhPJxSr9rimSNuVi67YqgFiK4iOKjoO2+uqCdfJOSyKrrKpJsd021nrdsAPvJ09p5gRZvByxmSVA== X-Received: by 2002:a62:19c8:0:b029:18a:ec5e:e68e with SMTP id 191-20020a6219c80000b029018aec5ee68emr1254631pfz.9.1605219096939; Thu, 12 Nov 2020 14:11:36 -0800 (PST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com. [209.85.210.174]) by smtp.gmail.com with ESMTPSA id w66sm7607418pfb.48.2020.11.12.14.11.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 14:11:36 -0800 (PST) Received: by mail-pf1-f174.google.com with SMTP id q5so5833775pfk.6 for ; Thu, 12 Nov 2020 14:11:36 -0800 (PST) X-Received: by 2002:a62:f245:0:b029:18b:df86:191c with SMTP id y5-20020a62f2450000b029018bdf86191cmr1354850pfl.35.1605219096550; Thu, 12 Nov 2020 14:11:36 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <14535.1605218623@localhost> In-Reply-To: <14535.1605218623@localhost> From: Ryan Sleevi Date: Thu, 12 Nov 2020 17:11:25 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Michael Richardson Cc: LAMPS , Erik Andersen Content-Type: multipart/alternative; boundary="00000000000009621f05b3f032bb" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 22:11:39 -0000 --00000000000009621f05b3f032bb Content-Type: text/plain; charset="UTF-8" On Thu, Nov 12, 2020 at 5:03 PM Michael Richardson wrote: > The RPs in question are EAP clients which do not have any connectivity > (yet) > with which to attempt to find info. > "Find info" is the abstract hand-wave that I was hoping could be more precisely elaborated on. If the certificate lacks a cRL DP and an OCSP AIA, where is the client going to find info, and how does it know to go there, and does any running code, in practice, actually do this? --00000000000009621f05b3f032bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 12, 2020 at 5:03 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:
The RPs in question are EAP clients which do not have any connectivity (yet= )
with which to attempt to find info.

&qu= ot;Find info" is the abstract hand-wave that I was hoping could be mor= e precisely elaborated on. If the certificate lacks a cRL DP and an OCSP AI= A, where is the client going to find info, and how does it know to go there= , and does any running code, in practice, actually do this?=C2=A0
--00000000000009621f05b3f032bb-- From nobody Thu Nov 12 20:36:36 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966723A148D for ; Thu, 12 Nov 2020 20:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=TO0tNeQH; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=kfaKnoJf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t75MlH_wgEcP for ; Thu, 12 Nov 2020 20:36:33 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623E63A1330 for ; Thu, 12 Nov 2020 20:36:33 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605242189; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=AT8tKk48LsHp0WZU8CqjYX+MU+0L7mhrBs0bcXKunfY=; b=TO0tNeQHoL/cKU1Y/x9s+UFxewrb2qfJYkYpwhZjoPrSjVWji7LAYAHq/FphT65dc67Gw a7iQVQvg7kOgrKfDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605242189; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=AT8tKk48LsHp0WZU8CqjYX+MU+0L7mhrBs0bcXKunfY=; b=kfaKnoJfQ2Wi0+bTEZn+kdtMfuQUbXAYiONMG0Hjao+KdLfbeClBAwlQBmOR8rVO1e+Tq 6azgQ3Z5grRcHFCra0e4vht5vcGLvYRdBE1DDpz83VjHEqeuGF/WVNrFdHmjy8zdkWHlxh2 n3eXD1kbyIE2MoP37b6t5lE0eLzNBhcdwEhhq+FYwDS8KDuRgNNmsSNMoXheukIZzlKsqqX o2UFpAXD2DAqfqddJ7n6J4ZnTtxHlBeOSjqEzj+pa9cQ2bGUfbp62oYJsVlA5aaj2E+Al8M IhyP0ji+2ahpgjXxDzFq8tY+NA8wlGXFJ7ymMlJMMuxpAUec9HzMsz22u2NQ== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id B15CCF9A5; Thu, 12 Nov 2020 23:36:29 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5F94920338; Thu, 12 Nov 2020 23:36:06 -0500 (EST) From: Daniel Kahn Gillmor To: Alexey Melnikov , IETF LAMPS WG In-Reply-To: <4F4638CC-090D-4530-90D1-674A91204ADD@vigilsec.com> References: <87lff8gy20.fsf@fifthhorseman.net> <20201111083652.xld5u5oenrfwt4wx@hezmatt.org> <874klvgrbj.fsf@fifthhorseman.net> <4F4638CC-090D-4530-90D1-674A91204ADD@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Thu, 12 Nov 2020 23:36:05 -0500 Message-ID: <87v9e9g9fu.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] X.509v3 extension with semantics "do not check CRLs or OCSP"? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 04:36:35 -0000 --=-=-= Content-Type: text/plain Alexey, given the discussion in this thread about id-ce-noRevAvail and id-pkix-ocsp-nocheck, i'm not sure what you would specifically recommend for the sample certificates. Can you give me more specific information about the failures that you saw while experimenting with those certs, and let me (and the list?) know what extensions you'd like to see set on the sample S/MIME certificates? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX64NNgAKCRDEDyVUMvKB DwsKAQDByxIi7dAXF1Yu/2hjGEDw/4VPUZrGTlm4KdB5njTP6wD/QZb20Fkj3wmG jiMrb1HJAhR7vH82f7j156+sBrSBRw8= =ykC/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 21:51:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7C03A1526 for ; Thu, 12 Nov 2020 21:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9YRAzHBJN7r for ; Thu, 12 Nov 2020 21:51:35 -0800 (PST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) (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 437D03A1522 for ; Thu, 12 Nov 2020 21:51:35 -0800 (PST) Received: by mail-pf1-f176.google.com with SMTP id c20so6703134pfr.8 for ; Thu, 12 Nov 2020 21:51:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TfndZCIhqEPxEgKrRZIqd5JNE8z5Ndb+Wj0hP/7hCtQ=; b=W6GV96qCFals+OyKsNjQIHvNx29ECae4PRbexfwTn2RvyPKFGa4ZVb8b7hY6mWJmsM VmPlZJAQq+iu2rqcH2W8Xw0X4nAcAo6OlzHJWkQqWHZOUUlEklxV7WcPqzsuSo94MS+Z EjSNjSBT9aL3g+t0pElcBtjkjmYZOMLcsrRQCMBztNvi2z2vBr+sZRCyWJrFceFfNfdR cV2xx9g3BZRrUYQCtN9iIuUVNqnW7rm6b6NtsFwUCJOCP7jP6B2ByTQzGzvigxpBtP0n FN8k4ssjuUCOI3XPHKtfHfN2p5h9sNqVmU/r4sPHMmh/I58BN1mNJkQzSxN22a3l7xaB tsOw== X-Gm-Message-State: AOAM530Agk9Iq/roZUZmwxvMpMQXv00qRCMOj/3QnfIitLBcuRj3uI9a cMfcBCwDtshHz+huT+lLSDal/0atT0w= X-Google-Smtp-Source: ABdhPJywat0sNwcrUoWXcE4pSoWXIQxdnNqRBseZc9odWWq/ryrGlDPCPteDl9Qw9gQQyP5doHOukw== X-Received: by 2002:a63:221a:: with SMTP id i26mr781381pgi.331.1605246694514; Thu, 12 Nov 2020 21:51:34 -0800 (PST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com. [209.85.215.181]) by smtp.gmail.com with ESMTPSA id z13sm7545249pgc.44.2020.11.12.21.51.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Nov 2020 21:51:34 -0800 (PST) Received: by mail-pg1-f181.google.com with SMTP id w4so6194009pgg.13 for ; Thu, 12 Nov 2020 21:51:33 -0800 (PST) X-Received: by 2002:a17:90b:3884:: with SMTP id mu4mr1061695pjb.202.1605246693707; Thu, 12 Nov 2020 21:51:33 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> In-Reply-To: From: Ryan Sleevi Date: Fri, 13 Nov 2020 00:51:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Mike Ounsworth Cc: Ryan Sleevi , Russ Housley , LAMPS , Erik Andersen Content-Type: multipart/alternative; boundary="000000000000f4979205b3f69e18" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 05:51:38 -0000 --000000000000f4979205b3f69e18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2020 at 6:41 PM Mike Ounsworth wrote: > > Concretely: If a certificate lacks OCSP or CRLs in-band, where is it > going to find the information? > > I=E2=80=99m not an OCSP expert, but a certificate without an OCSP AIA may= still > have an OCSP response stapled in the protocol? Sure, but where does this information come from, and how does that relate to "saving work", as proposed? Is a client expected to ignore such a response, not even bothering to parse it? Would "stapling" an MPEG of a cat as the OCSP response be a protocol violation, because it's not an OCSP response? Or would it be working as intended, because the extension says to ignore such responses? And is that a thing people have actually implemented or would want to? This also doesn't seem the scenario Russ was describing, given the remarks about short-term certificates, so it seems like this is speculating about some separate use case than what was originally presented. I'm not opposed to speculation, but it seemed like there was a concrete case in mind? > I have no personal experience with such a deployment, but I could imagine > closed-network PKIs where that makes sense. An id-ce-noRevAvail type cert > extension would allow an RP to distinguish between maliciously omitted OC= SP > responses, and certs that are not intended to have them. > If we're assuming the following scenario: 1) Server has an out-of-band configuration via some local policy on URLs for a repository to obtain revocation information from the CA 2) The issued certificate lacks any references at all to these repositories (e.g. no cRL DP, no OCSP AIA) 3) The client lacks such a locally-configured policy about that repository, and thus relies entirely on the server to provide such information And the goal is that if the client knows something affirmatively is not revocable, it will ignore the stapled data provided, which presumably would be something like a tryLater, or potentially a Good response valid for the lifetime of the cert. However, if it doesn't know it's not revocable, then ... what, it'll fail the connection? If that's the case, you can accomplish that same use case, today, by using RFC 7633 to affirmatively indicate on the certificates you *do* provide revocation information for that such information must be delivered by stapling or the connection is failed, and any certificates omitting it have the semantics of being presumed unrevocable, as the client lacks any revocation details. That can be implemented today, without the need to standardize any new extensions or define any processing semantics. The problem I'm having is that while I can speculate on an endless number of contrived cases (e.g. something that relies on the UNDETERMINED status of RFC 5280, 6.3.3's outputs that would meaningfully lead to a different behaviour than UNREVOKED, being able to skip looking up in LDAP for a CRL based on the DN of the cert, being able to skip parsing previously obtained CRL for that issuer, etc), I struggle to find a cohesive threat model or use case that they actually address, that can't be accomplished via other means, or that isn't tied to an unusual local policy configuration. That's why I was interested in trying to find out why id-ce-noRevAvail is seen as interesting for PKCs, and what it was that I was overlooking if there was a non-contrived case. There also seems considerable security risk in such extensions, much like what is discussed regarding id-pkix-ocsp-nocheck, so I was surprised there would be interest in such a remarkable footgun. --000000000000f4979205b3f69e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 12, 2020 at 6:41 PM Mike = Ounsworth <Mike.Ounsworth@= entrust.com> wrote:
> Concretely: If a certificate lacks OCSP or CRLs in-band, wh= ere is it going to find the information?

I=E2=80=99m not an OCSP expert, but a certificate without an OCSP AIA may s= till have an OCSP response stapled in the protocol?

Sure, but where does this information come from, and how does that= relate to "saving work", as proposed? Is a client expected to ig= nore such a response,=C2=A0not even bothering to parse it? Would "stap= ling" an MPEG of a cat as the OCSP response be a protocol violation, b= ecause it's not an OCSP response? Or would it be working as intended, b= ecause the extension says to ignore such responses? And is that a thing peo= ple have actually implemented or would want to?

Th= is also doesn't=C2=A0seem the scenario Russ was describing, given the r= emarks about short-term certificates, so it seems like this is speculating = about some separate use case than what was originally presented. I'm no= t opposed to speculation, but it seemed like there was a concrete case in m= ind?
=C2=A0
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 06:48:27 -0000 On 2020-11-13 06:51, Ryan Sleevi wrote: > > > On Thu, Nov 12, 2020 at 6:41 PM Mike Ounsworth > > wrote: > > > Concretely: If a certificate lacks OCSP or CRLs in-band, where is > it going to find the information? > > I’m not an OCSP expert, but a certificate without an OCSP AIA may > still have an OCSP response stapled in the protocol? > > > Sure, but where does this information come from, and how does that > relate to "saving work", as proposed? Is a client expected to ignore > such a response, not even bothering to parse it? Would "stapling" an > MPEG of a cat as the OCSP response be a protocol violation, because it's > not an OCSP response? Or would it be working as intended, because the > extension says to ignore such responses? And is that a thing people have > actually implemented or would want to? > > This also doesn't seem the scenario Russ was describing, given the > remarks about short-term certificates, so it seems like this is > speculating about some separate use case than what was originally > presented. I'm not opposed to speculation, but it seemed like there was > a concrete case in mind? >   > > I have no personal experience with such a deployment, but I could > imagine closed-network PKIs where that makes sense. An > id-ce-noRevAvail type cert extension would allow an RP to > distinguish between maliciously omitted OCSP responses, and certs > that are not intended to have them. > > > If we're assuming the following scenario: > 1) Server has an out-of-band configuration via some local policy on URLs > for a repository to obtain revocation information from the CA > 2) The issued certificate lacks any references at all to these > repositories (e.g. no cRL DP, no OCSP AIA) > 3) The client lacks such a locally-configured policy about that > repository, and thus relies entirely on the server to provide such > information > > And the goal is that if the client knows something affirmatively is not > revocable, it will ignore the stapled data provided, which presumably > would be something like a tryLater, or potentially a Good response valid > for the lifetime of the cert.  However, if it doesn't know it's not > revocable, then ... what, it'll fail the connection? > > If that's the case, you can accomplish that same use case, today, by > using RFC 7633 to affirmatively indicate on the certificates you *do* > provide revocation information for that such information must be > delivered by stapling or the connection is failed, and any certificates > omitting it have the semantics of being presumed unrevocable, as the > client lacks any revocation details. That can be implemented today, > without the need to standardize any new extensions or define any > processing semantics. > > The problem I'm having is that while I can speculate on an endless > number of contrived cases (e.g. something that relies on the > UNDETERMINED status of RFC 5280, 6.3.3's outputs that would meaningfully > lead to a different behaviour than UNREVOKED, being able to skip looking > up in LDAP for a CRL based on the DN of the cert, being able to skip > parsing previously obtained CRL for that issuer, etc), I struggle to > find a cohesive threat model or use case that they actually address, > that can't be accomplished via other means, or that isn't tied to an > unusual local policy configuration. > > That's why I was interested in trying to find out why id-ce-noRevAvail > is seen as interesting for PKCs, and what it was that I was overlooking > if there was a non-contrived case. There also seems considerable > security risk in such extensions, much like what is discussed regarding > id-pkix-ocsp-nocheck, so I was surprised there would be interest in such > a remarkable footgun. My comment (supporting Ryan at this time) is that we should abstain from adding more fields to certificates unless absolutely needed. Certificate fields are hard for end users to configure right as it is, for all various use cases they have. Every new field is a maintenance burden for users and should imho only be added with crystal clear motivation. Without a specific use case and benefit understood, for end devices to not check revocation seems to be the most common modus operandi today. Adding a field saying that devices should do what they already do seems superfluous and overloads the already overloaded PKI administrators. From nobody Thu Nov 12 22:55:48 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694B63A15B9 for ; Thu, 12 Nov 2020 22:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 Y9LvaNz2bmLW for ; Thu, 12 Nov 2020 22:55:41 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (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 5E8D93A15B4 for ; Thu, 12 Nov 2020 22:55:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QZ9WLJ20go/40rOHoMEWLFyI+pGAoZG5OiD8+WNQFNgIt6RuXg+Gu4tM7RinkeK0b3PQiOoD/CilqYwUYji7lv6jlmKhpoRb/8vFhJazF38d0le6j1aBMqhQIOd472Q+UZc1W/02sGFFnVSXKbJ0xey73ps4TyWtf5eBp9Rv3JN/GnkT/DMyP8OyEcPOlAMdO2ucOPSbuJB2gJ1s0x6qDoM53ql63bY5jrqLpUoFSzoo73eF7EF9+b11iFNRzhL1R5AWe2ScqTItYzp20vUubg+fGOJzn1r7TcpDxrem77WIBE4cdh3TyMTpYDXOyh+Y/cLHMopr7x/NiPcbVLSvTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EAJqHEUnVMvHsRehdcZ8PGLf+vijlqBQwRsruQmppts=; b=XUs3WiGdLqFPU0LrUhLbj0D5cdXO/OXVRa1xYeAkyuisbSDBmRl8Um7Dc8paXZyU95bj2zeSfAvn7TJFZ7pSXSMm2tKPJljip4TnP4fevyQjbJW6ebH4TFy6yroFENuPkdgEi4k6SRKZM0JpJ1EmRkDb/a1kwPX3Zk6K0G4jIKMXiFbq9schKRZkuytfoN7P/hG4KW3l4luB+U023QL2K6wZcPb3eW8JM96Wd7gzBqCtHDpvb6e8seaEBJV27Yf95yRsZOPOGD+3AwCJmZmlCjh0SLaGaUljhCTKNMmL6DzZZKrUdso5uXB6VpB7DjSTYLGPoS97j6GrLg1jX19zQg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EAJqHEUnVMvHsRehdcZ8PGLf+vijlqBQwRsruQmppts=; b=dlFI5tLS0ZWnxtRY92MgJyKP2PXTIFmFOKev4MwJSmcBaoc7/AsiYOaaLwjavLgQRtaks9fCw2KY2vGFjpxrz3NBQYoisIoDbSbrnUqssT7FqVzobF5Ffda5F04cXOwKeNx9Obe6xcq1BVRAXkiSx+Z5hQ52WYkEwi9bj4JzVN8= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4354.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:266::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Fri, 13 Nov 2020 06:55:38 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::48d8:f723:944:efe6]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::48d8:f723:944:efe6%6]) with mapi id 15.20.3499.032; Fri, 13 Nov 2020 06:55:38 +0000 From: "Brockhaus, Hendrik" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwATKpuw Date: Fri, 13 Nov 2020 06:55:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-13T06:55:37Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=11dbee44-f406-4526-918c-733dd111c419; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.180] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e201739a-6fcf-407c-bda4-08d887a120aa x-ms-traffictypediagnostic: AM9PR10MB4354: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: My2O+ZAgzDPSK8woo6wc39ElK92VZihfyNUwnV2jIeMpBUVfWPJrciy8uMlSUlw7RliiCNHbdQYt/Iqc0CrNYp6bRRPyFLIM3poXM3Ga667ZwVwZDSYlS+PBIZL3hvTtvxQFsq9ZIJR/DWHuuJIBa/Ptm/kXBMNBt3DE+p1ne1BSRTXOVThnd6ODBWzxe3stiS7UmVqZGQRXc2402lgOBaPFrC1mbSoIk08wyDRrisXPbXnT4oGNgnplAVPrfyXVU2OezIeBqhTFdhFHShH4pWDtzNQroE4Krmep1W4J+V4tc5HX4hYmE4K1/UEULjHV83kicWwzeNxzfJ8pAgRUX8w1hiRx5YRvxRFLMuHxFUz5USa2ZCCU2nD0/T2bBonEnr/4Ph33o4ebu7endA7n2A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(366004)(136003)(396003)(186003)(55016002)(8936002)(478600001)(4744005)(76116006)(9686003)(33656002)(316002)(110136005)(52536014)(7696005)(6506007)(66476007)(8676002)(64756008)(66946007)(66446008)(66556008)(2906002)(71200400001)(55236004)(966005)(26005)(86362001)(5660300002)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NqphMsCAtwkM+1YNow1LFjIalOU4jsgNN3Q4aUo6gtP+a+51ueoPjxFfrriZdWrokAyF8vS17xUClk7RcybtnIJh2AyId5AxxC3KSQF+qYUB46xx920R8posLNWL2sqy0PBce3Ycae/+mevwBPVVUnLvblRhq5vhHOmKF1MN4n9lsJN/Tx+o7TFxB9L6IPC8us5ZbwUy0Bzx1cCEc0IFcy+KyPkQ5exIoWyOVsXYWZaoIwDtlD2oC7OX4HNd5tRjoTfDBBNk8RtjgyHyy7OuQTXQrBysNWpT1rlH0OUF4gSFHvNs9VFLT2UI6COVHPIWqyQXUZqz4LfevetH4uRuqhZkiwDn9gWyZuACAQdWUiQ/4JLytxwg8EnsdOZlkSC9KPgBE1kWngLybGD3Wqs5NsYj5dLl6etonJVW2/+kGh7nd7fa6B7lE0J0xbKMRFzWW4vVYDyL6HipNBltMt5nRP6axlpQfs77p3DKmYAFhaL1wMklobnG8UATMe3ZFTVMtBY7lyaczBTYOBBvPO2UjsHtOFUbK89rR+3bynx+OqQY0Ar7FHIQCx0CyKR8+DgjI68mX03VPSjpYvLEddb+vI2ZcGBroE5bB0VMrL3IQVCB0wSSXlVGKEJX9B/ZLvzJooLWtVXkR35PPTLMcGxrNQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24181533C788F9B3F25CB942FEE60AM0PR10MB2418EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e201739a-6fcf-407c-bda4-08d887a120aa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 06:55:37.9770 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J7qKiHMy88XVhmrm/PBNQvVNV9ItIpr1QS5JGRaxjvWwgJOrxHr93FlS7PEA7fhJ08YUdHHA+Y/wV6pJPxRLmqAU0kZ7UPSe8XiExhjLwok= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4354 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 06:55:45 -0000 --_000_AM0PR10MB24181533C788F9B3F25CB942FEE60AM0PR10MB2418EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do support the adoption. Hendrik Von: Spasm Im Auftrag von Tim Hollebeek Gesendet: Donnerstag, 12. November 2020 22:51 An: LAMPS Betreff: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg For those of you who are following the discussion, you're probably aware of= the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use withi= n CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<= https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=3D04= %7C01%7Chendrik.brockhaus%40siemens.com%7C7a072c28d1ef4fa9325708d887552164%= 7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637408146986106192%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C2000&sdata=3D79NiNrw4qUDVsfz62XcDeaqX26QUEG%2BnHrm%2FFnPNsGc%3D&rese= rved=3D0> Please indicate by November 25th whether you support adoption of draft-hous= ley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim --_000_AM0PR10MB24181533C788F9B3F25CB942FEE60AM0PR10MB2418EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do support the adoption.

 

Hendrik

 

Von: Spasm <spasm-bounces@ietf.org> = Im Auftrag von Tim Hollebeek
Gesendet: Donnerstag, 12. November 2020 22:51
An: LAMPS <spasm@ietf.org>
Betreff: [lamps] Call for adoption of draft-housley-lamps-cms-aes-ma= c-alg

 

For those of you who are follow= ing the discussion, you’re probably aware of the following brief draf= t that is related to the CMP work.

It allocates an OID for AES-GMA= C, and contains provisions for its use within CMS.  The draft is avail= able here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.tx= t

 

Please indicate by November 25<= sup>th whether you support adoption of draft-housley-lamps-cms-aes-ma= c-alg by the LAMPS WG.

 

-Tim

 

--_000_AM0PR10MB24181533C788F9B3F25CB942FEE60AM0PR10MB2418EURP_-- From nobody Fri Nov 13 06:12:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956DF3A0C1D for ; Fri, 13 Nov 2020 06:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDsxyHKPsLlK for ; Fri, 13 Nov 2020 06:12:12 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E5D3A0962 for ; Fri, 13 Nov 2020 06:12:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 237EA300B2B for ; Fri, 13 Nov 2020 09:12:10 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kvVcTIKBOeMo for ; Fri, 13 Nov 2020 09:12:08 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 4445D300AEB; Fri, 13 Nov 2020 09:12:08 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D6023A4F-D5B0-4A42-B310-FA6A6066D3AA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 13 Nov 2020 09:12:08 -0500 In-Reply-To: <16255.1605219019@localhost> Cc: LAMPS To: Michael Richardson References: <16255.1605219019@localhost> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 14:12:16 -0000 --Apple-Mail=_D6023A4F-D5B0-4A42-B310-FA6A6066D3AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 12, 2020, at 5:10 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Tim Hollebeek wrote: >> = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt= >=20 >=20 >=20 >> Please indicate by November 25th whether you support adoption of >> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. >=20 > Seems short and to the point. >=20 > An example message in an appendix would be nice. Sure. That is something I can do in the next version. Russ --Apple-Mail=_D6023A4F-D5B0-4A42-B310-FA6A6066D3AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCX66UOQAKCRCK5O7Q9ZwR y1RzAJwJjmp/VYhhY85ijvIXJvXd6CBg2wCgz19Gh6ONRuN4VELMAoD3p2Cn9co= =5fUy -----END PGP SIGNATURE----- --Apple-Mail=_D6023A4F-D5B0-4A42-B310-FA6A6066D3AA-- From nobody Fri Nov 13 06:21:42 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E084A3A0C88 for ; Fri, 13 Nov 2020 06:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocOvWKlxMo89 for ; Fri, 13 Nov 2020 06:21:38 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FD13A0C82 for ; Fri, 13 Nov 2020 06:21:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 163EE300B64 for ; Fri, 13 Nov 2020 09:21:36 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id g-8c0UfIv1_m for ; Fri, 13 Nov 2020 09:21:33 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 69F14300BA2; Fri, 13 Nov 2020 09:21:33 -0500 (EST) From: Russ Housley Message-Id: <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1D769C11-3DB6-4D2D-A078-B3CDE279A887" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 13 Nov 2020 09:21:34 -0500 In-Reply-To: Cc: LAMPS , Erik Andersen To: Ryan Sleevi References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 14:21:41 -0000 --Apple-Mail=_1D769C11-3DB6-4D2D-A078-B3CDE279A887 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ryan: > On Thu, Nov 12, 2020 at 4:44 PM Russ Housley > wrote: >> It's not immediately obvious the value proposition of "affirmatively = asserting no" vs the status quo of "definitively not asserting any = information source", and under what processing model a client would find = it useful or important to distinguish these cases. >=20 > The difference is the processing time it takes for the RP to try to = find information when the CA knows in advance that there never will be = any. >=20 > I'm sorry, I think you answered a different question than I was = asking, so I'll try to rephrase it using your response. I'm not asking = about "why would you use shortlived certificates", I'm trying to = understand what you see as the steps the RP takes to "try to find = information", if no references to such information are made available to = the RP within the certificate. >=20 > Concretely: If a certificate lacks OCSP or CRLs in-band, where is it = going to find the information? >=20 > Is the assumption that the client will be performing LDAP directory = checks based on the DN of the cert, as envisaged in X.509v1? > Is the assumption that the client is locally configured to support = some local configuration that points to a repository with revocation? >=20 > In order for there to be steps that are skipped, there needs to be a = statement of what steps are performed. We can "obviously" disable CRLs = and OCSP by simply not providing such information in the certificate, so = I was hoping you could articulate what other sources of information that = might be used by a client where such an affirmative expression would be = relevant and necessary. I have heard about several application, not in the Web PKI, where a very = short lived certificate is being used. In one extreme case, a key is = generated, certified, used for one signature, and destroyed. Russ= --Apple-Mail=_1D769C11-3DB6-4D2D-A078-B3CDE279A887 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ryan:

On Thu, Nov = 12, 2020 at 4:44 PM Russ Housley <housley@vigilsec.com> wrote:
It's not immediately obvious the = value proposition of "affirmatively asserting no" vs the status quo of = "definitively not asserting any information source", and under what = processing model a client would find it useful or important to = distinguish these cases.

The difference is the processing time it = takes for the RP to try to find information when the CA knows in advance = that there never will be any.

I'm sorry, I think you = answered a different question than I was asking, so I'll try to rephrase = it using your response. I'm not asking about "why would you use = shortlived certificates", I'm trying to understand what you see as the = steps the RP takes to "try to find information", if no references to = such information are made available to the RP within the = certificate.

Concretely: If a certificate lacks OCSP or CRLs in-band, = where is it going to find the information?

Is the assumption that the client will = be performing LDAP directory checks based on the DN of the cert, as = envisaged in X.509v1?
Is the assumption that the = client is locally configured to support some local configuration that = points to a repository with revocation?

In order for there to be steps that are = skipped, there needs to be a statement of what steps are performed. We = can "obviously" disable CRLs and OCSP by simply not providing such = information in the certificate, so I was hoping you could articulate = what other sources of information that might be used by a client where = such an affirmative expression would be relevant and = necessary.

I have = heard about several application, not in the Web PKI, where a very short = lived certificate is being used.  In one extreme case, a key is = generated, certified, used for one signature, and destroyed.

Russ
= --Apple-Mail=_1D769C11-3DB6-4D2D-A078-B3CDE279A887-- From nobody Fri Nov 13 06:55:17 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055013A0D84 for ; Fri, 13 Nov 2020 06:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKsiNWSXUrYI for ; Fri, 13 Nov 2020 06:55:14 -0800 (PST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (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 681B23A0D7B for ; Fri, 13 Nov 2020 06:55:14 -0800 (PST) Received: by mail-pf1-f169.google.com with SMTP id c66so7830803pfa.4 for ; Fri, 13 Nov 2020 06:55:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2TVQcqayIuerb1pD2NxkLZqeGeNPAPMUuYogv63ciw0=; b=f6p4cpkuKShoByiQlDsIY7BSOGH2UMKZ/MXVK2OF9SOrpLia6a8JBc7hV0vwBe7TZE lD28U0hcmlX9umzUyjQyG/VcONq2govDZY52sjfXWc64Hak//q4TzdPGzquw4CWVpksG j/Rw1GITGr2aaTeyQHtha3bG7lbenGEe+ehA1QLf8h0icPz8UVZFMds+7SMdjdcx98Wi LDcPl4ky7zKviI+sVtWtIMS+ZMYSNdTkPFIGUEUSa3fA2yFuyVX1SAH7GuzW8xKj4tXN hWIq0G1CUR+frpidcOCz/gjbSrHtVMRJryPSKw0EbfWu8mA7MZEFG1N4EGbrgBFt8IlM AePA== X-Gm-Message-State: AOAM530YcMtGmTAy4fXT5z0939dcBQfPja60MsBPeun9SoG4Vf9+QpeK znevQLDh87yqc6sDkkfOHvNeTaZjz84= X-Google-Smtp-Source: ABdhPJwV91ENc/UU8t9rIhDbGI/dAWiHZ/QKcpa0Huu6uAJWYr/qiKwU/9wjapOln3HqSfOZ5frysA== X-Received: by 2002:a17:90a:4816:: with SMTP id a22mr3550403pjh.228.1605279313422; Fri, 13 Nov 2020 06:55:13 -0800 (PST) Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com. [209.85.210.169]) by smtp.gmail.com with ESMTPSA id o132sm9842208pfg.100.2020.11.13.06.55.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Nov 2020 06:55:13 -0800 (PST) Received: by mail-pf1-f169.google.com with SMTP id w6so7840915pfu.1 for ; Fri, 13 Nov 2020 06:55:13 -0800 (PST) X-Received: by 2002:a17:90a:5d17:: with SMTP id s23mr3431709pji.103.1605279312846; Fri, 13 Nov 2020 06:55:12 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> In-Reply-To: <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> From: Ryan Sleevi Date: Fri, 13 Nov 2020 09:55:02 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Erik Andersen , LAMPS , Ryan Sleevi Content-Type: multipart/alternative; boundary="0000000000003524a005b3fe37b5" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 14:55:16 -0000 --0000000000003524a005b3fe37b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 9:21 AM Russ Housley wrote: > Ryan: > > On Thu, Nov 12, 2020 at 4:44 PM Russ Housley wrote= : > >> It's not immediately obvious the value proposition of "affirmatively >> asserting no" vs the status quo of "definitively not asserting any >> information source", and under what processing model a client would find= it >> useful or important to distinguish these cases. >> >> >> The difference is the processing time it takes for the RP to try to find >> information when the CA knows in advance that there never will be any. >> > > I'm sorry, I think you answered a different question than I was asking, s= o > I'll try to rephrase it using your response. I'm not asking about "why > would you use shortlived certificates", I'm trying to understand what you > see as the steps the RP takes to "try to find information", if no > references to such information are made available to the RP within the > certificate. > > Concretely: If a certificate lacks OCSP or CRLs in-band, where is it goin= g > to find the information? > > Is the assumption that the client will be performing LDAP directory check= s > based on the DN of the cert, as envisaged in X.509v1? > Is the assumption that the client is locally configured to support some > local configuration that points to a repository with revocation? > > In order for there to be steps that are skipped, there needs to be a > statement of what steps are performed. We can "obviously" disable CRLs an= d > OCSP by simply not providing such information in the certificate, so I wa= s > hoping you could articulate what other sources of information that might = be > used by a client where such an affirmative expression would be relevant a= nd > necessary. > > > I have heard about several application, not in the Web PKI, where a very > short lived certificate is being used. In one extreme case, a key is > generated, certified, used for one signature, and destroyed. > > Russ > Yes, I am also aware of such systems, and tried to acknowledge as much in my previous messages. However, this response is still a handwave that doesn=E2=80=99t address the= very real and practical question: how would such systems process certificates differently in light of such an extension? I=E2=80=99m not sure how to reword my question to make it clearer, but it= =E2=80=99s the same question I=E2=80=99ve been asking from the start. I=E2=80=99m hoping to get you to describe a validation process - a set of i= nputs, an algorithm, and outputs - where this extension would result in a meaningful difference compared to just omitting OCSP AIA and CRL DPs. In order for this to be useful, I imagine there has to be some algorithm that, should this exist on PKCs, would produce a different output if all inputs were the same, save for the existence of this extension. This is hopefully a fairly basic question, but it=E2=80=99s vitally important to get a clear = answer, because it allows us to ask =E2=80=9Care there other ways to get the same o= utput=E2=80=9D (e.g. the omission of CRL DPs and OCSP AIA). Whether you want to frame it in terms of proceeding of RFC 5280 Section 6, or frame it in terms of running code that folks implement today, I=E2=80=99m ambivalent, but it=E2= =80=99s essential to discuss the desired output, since the claim is implicitly that there=E2= =80=99s no way to accomplish this today, and the extension is the only way. If a behavior change is not desired, then is the view that this has no semantic impact on processing, does not alter any semantic meaning, and is merely a syntactical declaration by the CA? Such a declaration is functionally equivalent to a comment in code, and meant to assist those who manually inspect and personally review each certificate, rather than having any bearing on code. --0000000000003524a005b3fe37b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 13, 2020 at 9:21 AM Russ Housley <housley@vigilsec.com> wrote:
=
Ryan:

O= n Thu, Nov 12, 2020 at 4:44 PM Russ Housley <housley@vigilsec.com> wrote:
It&#= 39;s not immediately obvious the value proposition of "affirmatively a= sserting no" vs the status quo of "definitively not asserting any= information source", and under what processing model a client would f= ind it useful or important to distinguish these cases.

The difference is the processing time it tak= es for the RP to try to find information when the CA knows in advance that = there never will be any.

= I'm sorry, I think you answered a different question than I was asking,= so I'll try to rephrase it using your response. I'm not asking abo= ut "why would you use shortlived certificates", I'm trying to= understand what you see as the steps the RP takes to "try to find inf= ormation", if no references to such information are made available to = the RP within the certificate.

Concretely: If a ce= rtificate lacks OCSP or CRLs in-band, where is it going to find the informa= tion?

Is the assumption that the client will be pe= rforming LDAP directory checks based on the DN of the cert, as envisaged in= X.509v1?
Is the assumption that the client is locally configured= to support some local configuration that points to a repository with revoc= ation?

In order for there to be steps that are ski= pped, there needs to be a statement of what steps are performed. We can &qu= ot;obviously" disable CRLs and OCSP by simply not providing such infor= mation in the certificate, so I was hoping you could articulate what other = sources of information that might be used by a client where such an affirma= tive expression would be relevant and necessary.

I have heard about several application,= not in the Web PKI, where a very short lived certificate is being used.=C2= =A0 In one extreme case, a key is generated, certified, used for one signat= ure, and destroyed.

Russ

Yes, I am also aware of such syste= ms, and tried to acknowledge as much in my previous messages.

However, this response is still a han= dwave that doesn=E2=80=99t address the very real and practical question: ho= w would such systems process certificates differently in light of such an e= xtension?

I=E2=80=99m no= t sure how to reword my question to make it clearer, but it=E2=80=99s the s= ame question I=E2=80=99ve been asking from the start.

I=E2=80=99m hoping to get you to describe a v= alidation process - a set of inputs, an algorithm, and outputs - where this= extension would result in a meaningful difference compared to just omittin= g OCSP AIA and CRL DPs. In order for this to be useful, I imagine there has= to be some algorithm that, should this exist on PKCs, would produce a diff= erent output if all inputs were the same, save for the existence of this ex= tension. This is hopefully a fairly basic question, but it=E2=80=99s vitall= y important to get a clear answer, because it allows us to ask =E2=80=9Care= there other ways to get the same output=E2=80=9D (e.g. the omission of CRL= DPs and OCSP AIA). Whether you want to frame it in terms of proceeding of = RFC 5280 Section 6, or frame it in terms of running code that folks impleme= nt today, I=E2=80=99m ambivalent, but it=E2=80=99s essential to discuss the= desired output, since the claim is implicitly that there=E2=80=99s no way = to accomplish this today, and the extension is the only way.

If a behavior change is not desired, = then is the view that this has no semantic impact on processing, does not a= lter any semantic meaning, and is merely a syntactical declaration by the C= A? Such a declaration is functionally equivalent to a comment in code, and = meant to assist those who manually inspect and personally review each certi= ficate, rather than having any bearing on code.
--0000000000003524a005b3fe37b5-- From nobody Fri Nov 13 06:58:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF7D3A0D8B; Fri, 13 Nov 2020 06:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 XYeb8ZGNtSx4; Fri, 13 Nov 2020 06:58:05 -0800 (PST) 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 13D733A0DBD; Fri, 13 Nov 2020 06:58:04 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0ADEoXYh027888; Fri, 13 Nov 2020 14:58:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hM0cNL+FLmvN0EHt733VO/daI+EraT7/L9xy1orq4lA=; b=iidM1lGzvGx1JbpB31/XkkFr339aG3fq7jGs2TH5i2bLTjnWS9TgPC3/mQy27PWBns4H VHYsRQF8qd+W/j14/DZrRA5Hz7pOcDSVZ/YTrh/QYIF4VqVztiGyRkfZmRJ2pvNtbd2K sRH8xy/hOKToVDuaRg4Ta/pnzUns16WG55RTBF60nG3Rw8SO4iJ7x+UPI1HHjh/Dx67T YVQIk+2u0FZPk1EZoUI6Vun8lKm77gpO+KT/LCg1Ybf1COC1upgweRjJby9/p3A/ggaW QmlykL1irRlk1V6AgGJtGF231P70ZJ6EEIQH6A4iLFTtLBGMWQqdP2RNi0ywgJdP0zgI aA== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 34p0b55693-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 14:58:04 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0ADEnuWu030862; Fri, 13 Nov 2020 09:58:03 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint4.akamai.com with ESMTP id 34ss2n12kc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 09:58:03 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 08:58:02 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Fri, 13 Nov 2020 08:58:02 -0600 From: "Salz, Rich" To: Michael Richardson , Tim Hollebeek CC: LAMPS Thread-Topic: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwANZ56AABi3VYA= Date: Fri, 13 Nov 2020 14:58:01 +0000 Message-ID: <9510208E-6E71-4254-A701-E077AFABA4F2@akamai.com> References: <16255.1605219019@localhost> In-Reply-To: <16255.1605219019@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <342E4A0E3A847A459BDF4933C4FDC318@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=710 mlxscore=0 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 spamscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 impostorscore=0 phishscore=0 malwarescore=0 clxscore=1011 mlxlogscore=633 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130094 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 14:58:07 -0000 PiAgICBTZWVtcyBzaG9ydCBhbmQgdG8gdGhlIHBvaW50Lg0KDQo+ICAgIEFuIGV4YW1wbGUgbWVz c2FnZSBpbiBhbiBhcHBlbmRpeCB3b3VsZCBiZSBuaWNlLg0KDQpXaGF0IGhlIHNhaWQuDQoNCg== From nobody Fri Nov 13 07:12:18 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DE23A0D87 for ; Fri, 13 Nov 2020 07:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Fi8Fh8jWmgHP for ; Fri, 13 Nov 2020 07:12:15 -0800 (PST) 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 CDC0A3A0D7B for ; Fri, 13 Nov 2020 07:12:15 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ADF8m54024366; Fri, 13 Nov 2020 15:12:05 GMT 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=dpIzRQ8q3EoJ3fNSulJ+inC+y0yPy4GnUBdnh+NwiaU=; b=SdjKly37KgLSm7YWEbAXELVF3AmmPOx9TEZzNjMX5/+yzWVfQY5cKRfj//QFV4pRPV3q 2kzjRs0WfGXVuHe9Oy461YPfgHs4N9d1UIro7FxWY70q/Ybjs+inHDPC4qXs9K1eDsoi GfACEtaJCVnNQlLyO6v6uLdMJQDO7xUpo2DfcNxPlJOw/KoDDGiPGisPXvC2F7fV5KEl 0y4O3GXdOs757MgI5e/cscBNgPuxOcyFPbGZumNKTGTmCXfTr0XmA/QgXtlWZb7T6D6g 4DzIma+J/rUL9dMsIUC7P/S7ZXcu8xeRiwV59P4Vcl9M91pTPMZt4lvfFs3J/m+Y4BVd oA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34nkqr9e1c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 15:12:05 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0ADF4FFB003155; Fri, 13 Nov 2020 10:12:04 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 34ssads292-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 10:12:04 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 09:12:03 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Fri, 13 Nov 2020 09:12:03 -0600 From: "Salz, Rich" To: Ryan Sleevi , Mike Ounsworth CC: LAMPS , Erik Andersen , Russ Housley Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWuYEUtsOPs9cBU0CEVjtTNvJyM6nGPG2A Date: Fri, 13 Nov 2020 15:12:02 +0000 Message-ID: <1AE609AB-6A22-40C2-8707-A96D3DC56179@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@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/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_1AE609AB6A2240C28707A96D3DC56179akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 phishscore=0 mlxlogscore=782 adultscore=0 suspectscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130096 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1011 bulkscore=0 impostorscore=0 phishscore=0 adultscore=0 malwarescore=0 mlxlogscore=705 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130096 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 15:12:17 -0000 --_000_1AE609AB6A2240C28707A96D3DC56179akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgU3VyZSwgYnV0IHdoZXJlIGRvZXMgdGhpcyBpbmZvcm1hdGlvbiBjb21lIGZyb20NCg0K QWthbWFpIGFsbG93cyBpdHMgY3VzdG9tZXJzIHRvIGNvbmZpZ3VyZSB0aGUgVVJMIGZvciBPQ1NQ IHJlc3BvbmRlcnMuICBOb3QgbWFueSBkbyBzbywgb2YgY291cnNlLCBidXQgdGhvc2UgdGhhdCB1 c2UgaXQgd2FudCBpdCBiYWRseS4NCg0K --_000_1AE609AB6A2240C28707A96D3DC56179akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <75C4294AB3941941AE1CC830D8F3C4A5@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjExNjQ3Nzg4ODA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE1NDUyNjMxODYgLTc3MDY4NjczOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPlN1cmUsIGJ1dCB3aGVyZSBkb2VzIHRoaXMgaW5mb3JtYXRpb24gY29tZSBmcm9tPG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFrYW1haSBhbGxvd3MgaXRzIGN1c3RvbWVycyB0 byBjb25maWd1cmUgdGhlIFVSTCBmb3IgT0NTUCByZXNwb25kZXJzLiZuYnNwOyBOb3QgbWFueSBk byBzbywgb2YgY291cnNlLCBidXQgdGhvc2UgdGhhdCB1c2UgaXQgd2FudCBpdCBiYWRseS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_1AE609AB6A2240C28707A96D3DC56179akamaicom_-- From nobody Fri Nov 13 07:17:36 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D623A0DF6 for ; Fri, 13 Nov 2020 07:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OD9k6S6DwPn for ; Fri, 13 Nov 2020 07:17:26 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC803A0DD1 for ; Fri, 13 Nov 2020 07:17:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5B016300B4C for ; Fri, 13 Nov 2020 10:17:23 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PVWHnVlEPOz6 for ; Fri, 13 Nov 2020 10:17:20 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 7DED9300AF1; Fri, 13 Nov 2020 10:17:20 -0500 (EST) From: Russ Housley Message-Id: <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B33DA6A6-5367-4E29-8A5F-3AC23FB647B1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 13 Nov 2020 10:17:21 -0500 In-Reply-To: Cc: Erik Andersen , LAMPS To: Ryan Sleevi References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 15:17:35 -0000 --Apple-Mail=_B33DA6A6-5367-4E29-8A5F-3AC23FB647B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 13, 2020, at 9:55 AM, Ryan Sleevi wrote: >=20 >=20 >=20 > On Fri, Nov 13, 2020 at 9:21 AM Russ Housley > wrote: > Ryan: >=20 >> On Thu, Nov 12, 2020 at 4:44 PM Russ Housley > wrote: >>> It's not immediately obvious the value proposition of "affirmatively = asserting no" vs the status quo of "definitively not asserting any = information source", and under what processing model a client would find = it useful or important to distinguish these cases. >>=20 >> The difference is the processing time it takes for the RP to try to = find information when the CA knows in advance that there never will be = any. >>=20 >> I'm sorry, I think you answered a different question than I was = asking, so I'll try to rephrase it using your response. I'm not asking = about "why would you use shortlived certificates", I'm trying to = understand what you see as the steps the RP takes to "try to find = information", if no references to such information are made available to = the RP within the certificate. >>=20 >> Concretely: If a certificate lacks OCSP or CRLs in-band, where is it = going to find the information? >>=20 >> Is the assumption that the client will be performing LDAP directory = checks based on the DN of the cert, as envisaged in X.509v1? >> Is the assumption that the client is locally configured to support = some local configuration that points to a repository with revocation? >>=20 >> In order for there to be steps that are skipped, there needs to be a = statement of what steps are performed. We can "obviously" disable CRLs = and OCSP by simply not providing such information in the certificate, so = I was hoping you could articulate what other sources of information that = might be used by a client where such an affirmative expression would be = relevant and necessary. >=20 > I have heard about several application, not in the Web PKI, where a = very short lived certificate is being used. In one extreme case, a key = is generated, certified, used for one signature, and destroyed. >=20 > Russ >=20 > Yes, I am also aware of such systems, and tried to acknowledge as much = in my previous messages. >=20 > However, this response is still a handwave that doesn=E2=80=99t = address the very real and practical question: how would such systems = process certificates differently in light of such an extension? It would not look for a CRL or OCSP Responder. > I=E2=80=99m not sure how to reword my question to make it clearer, but = it=E2=80=99s the same question I=E2=80=99ve been asking from the start. >=20 > I=E2=80=99m hoping to get you to describe a validation process - a set = of inputs, an algorithm, and outputs - where this extension would result = in a meaningful difference compared to just omitting OCSP AIA and CRL = DPs. In order for this to be useful, I imagine there has to be some = algorithm that, should this exist on PKCs, would produce a different = output if all inputs were the same, save for the existence of this = extension. This is hopefully a fairly basic question, but it=E2=80=99s = vitally important to get a clear answer, because it allows us to ask = =E2=80=9Care there other ways to get the same output=E2=80=9D (e.g. the = omission of CRL DPs and OCSP AIA). Whether you want to frame it in terms = of proceeding of RFC 5280 Section 6, or frame it in terms of running = code that folks implement today, I=E2=80=99m ambivalent, but it=E2=80=99s = essential to discuss the desired output, since the claim is implicitly = that there=E2=80=99s no way to accomplish this today, and the extension = is the only way. Some systems, especially ones with that use LDAP or X.500 Directory, = look there for CRLs even if there is not a CRLDP extension. This = extension says to not do so. > If a behavior change is not desired, then is the view that this has no = semantic impact on processing, does not alter any semantic meaning, and = is merely a syntactical declaration by the CA? Such a declaration is = functionally equivalent to a comment in code, and meant to assist those = who manually inspect and personally review each certificate, rather than = having any bearing on code. Russ --Apple-Mail=_B33DA6A6-5367-4E29-8A5F-3AC23FB647B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 13, 2020, at 9:55 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:



On Fri, Nov = 13, 2020 at 9:21 AM Russ Housley <housley@vigilsec.com> wrote:
Ryan:

On Thu, Nov = 12, 2020 at 4:44 PM Russ Housley <housley@vigilsec.com> wrote:
It's = not immediately obvious the value proposition of "affirmatively = asserting no" vs the status quo of "definitively not asserting any = information source", and under what processing model a client would find = it useful or important to distinguish these = cases.

The difference is the processing time it takes for the = RP to try to find information when the CA knows in advance that there = never will be any.

I'm sorry, I think you answered a = different question than I was asking, so I'll try to rephrase it using = your response. I'm not asking about "why would you use shortlived = certificates", I'm trying to understand what you see as the steps the RP = takes to "try to find information", if no references to such information = are made available to the RP within the certificate.

Concretely: If a = certificate lacks OCSP or CRLs in-band, where is it going to find the = information?

Is = the assumption that the client will be performing LDAP directory checks = based on the DN of the cert, as envisaged in X.509v1?
Is the assumption that the client is locally configured to = support some local configuration that points to a repository with = revocation?

In = order for there to be steps that are skipped, there needs to be a = statement of what steps are performed. We can "obviously" disable CRLs = and OCSP by simply not providing such information in the certificate, so = I was hoping you could articulate what other sources of information that = might be used by a client where such an affirmative expression would be = relevant and necessary.

I have heard about several application, not = in the Web PKI, where a very short lived certificate is being = used.  In one extreme case, a key is generated, certified, used for = one signature, and destroyed.

Russ

Yes, I am also aware of = such systems, and tried to acknowledge as much in my previous = messages.

However, this response is still a handwave that = doesn=E2=80=99t address the very real and practical question: how would = such systems process certificates differently in light of such an = extension?

It would not look for a CRL or OCSP = Responder.

I=E2=80=99m not sure how to reword my question = to make it clearer, but it=E2=80=99s the same question I=E2=80=99ve been = asking from the start.

I=E2=80=99m hoping to get = you to describe a validation process - a set of inputs, an algorithm, = and outputs - where this extension would result in a meaningful = difference compared to just omitting OCSP AIA and CRL DPs. In order for = this to be useful, I imagine there has to be some algorithm that, should = this exist on PKCs, would produce a different output if all inputs were = the same, save for the existence of this extension. This is hopefully a = fairly basic question, but it=E2=80=99s vitally important to get a clear = answer, because it allows us to ask =E2=80=9Care there other ways to get = the same output=E2=80=9D (e.g. the omission of CRL DPs and OCSP AIA). = Whether you want to frame it in terms of proceeding of RFC 5280 Section = 6, or frame it in terms of running code that folks implement today, = I=E2=80=99m ambivalent, but it=E2=80=99s essential to discuss the = desired output, since the claim is implicitly that there=E2=80=99s no = way to accomplish this today, and the extension is the only = way.

Some = systems, especially ones with that use LDAP or X.500 Directory, look = there for CRLs even if there is not a CRLDP extension.  This = extension says to not do so.

If a behavior change = is not desired, then is the view that this has no semantic impact on = processing, does not alter any semantic meaning, and is merely a = syntactical declaration by the CA? Such a declaration is functionally = equivalent to a comment in code, and meant to assist those who manually = inspect and personally review each certificate, rather than having any = bearing on code.

Russ

= --Apple-Mail=_B33DA6A6-5367-4E29-8A5F-3AC23FB647B1-- From Mike.Ounsworth@entrust.com Thu Nov 12 15:41:22 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9DC3A101E for ; Thu, 12 Nov 2020 15:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=bcoe68HN; dkim=pass (2048-bit key) header.d=entrust.com header.b=Kblw7TOi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9p24HT4sn9Er for ; Thu, 12 Nov 2020 15:41:21 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 D55873A0FF6 for ; Thu, 12 Nov 2020 15:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1605224480; x=1636760480; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=bcoe68HN5Wb+ywoBaKSaoVB3rAHg8R9hWPnV0GReGw93EJn4dkpdX/Pr J8wR8l6+T4YVIjOKgkgdPI0uZhxwRxkJ67Ymfh5UdsDurAoqEjJjsDyqc U43+ex8JN7JI4rp7Tz7wlNDCKz7Gc0aueS+Oz/FsgoNUUHbGMGSrrJprY 8c0QFsue1qN/Dqjf++A5TK4AEqMDhzLpb/uf7CFeKKK35vC5c3BKF9wPo zyR6sUw7gsEb/zTg4wFf94i2waUoK0OmPopZbc5GZ+CyNyCjeB5GOS8ER 5MbqPTfbIJh7T/tbrFTSU0ZZRXuic1wPoC71hFrFERDBqLGrahkKrUlDU w==; IronPort-SDR: BXuckio0wD0plbhrO+0bdxTqCj1b12KMndnq+Q9XOW6gALp8KiztsvxYsiNHYXOdbywtsVOnQA uSVP4hBYmSGA== X-IronPort-AV: E=Sophos;i="5.77,473,1596517200"; d="scan'208";a="23403846" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 12 Nov 2020 17:41:16 -0600 Received: from PMSPEX03.corporate.datacard.com (192.168.211.50) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 12 Nov 2020 17:41:16 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 12 Nov 2020 17:41:16 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YRHGmjn2R+RlQfVwmVtvBz4BvQkC7put3//kZjQ8egXlaZYm05IItk+oSBNM7DztJ253TvNhJ/5vsia4mx1Jy19w5kdFFxZw5+whR2KvXyxgxya50gKStOxG3ixtBiNOa4/ebnqUxhkCBqnbzldbBd68wy1zzflsRRvelGvy711gYaut24WigQhpvPVQa0BCIRHCfavQatDOMwoD443s9RGWr95m/kzHzOhiPqVjXAHs03yTkekNv2bpM8+1C/feHK2MkLUYVnG9/nDyS9RFqAoqSzt7zltVOc69f21oFS9EwbWyuE/21/MvcSSLHLt71XWj1aqnbWug+c4a79ssHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=Z4HnIn+YzTnkh4slpYTbxcqpnza2PeHu2lSVkBV/xV9f0gSLScfL1nUVtN6inlhML1X156uOfdyOqbh7HAnf72AIT6fzcW2ycB3pGhnO/6RG65xUeKvVwaPBavaSXt+5Lg6ZYtsGsCDCiSHjUov4v7N44ElvtCSo867q5xySl4cVQN9EX9RUFdgT4Q6+nafN1THbH3mOmFE7aJOqr+103Eapia1WrSWd6NrOWE0Io2okNn+JJa4YCknfwv2BcZnoWt4kQT29/uSQny0gqOlMKuIM8+Tsl349FGX8NSwq7wf12xY8pSsrCtDxi7dvRBS7OyrxwIKk7Yo9A11HxovZjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=Kblw7TOi/zGnjWX45IZRBpIJUldfVbHyHC+U5MrNvbApE5n/3CffCnq0QoqRxnidHMCcFF5R63/mPo555nty0AkZV8f8SejbOAhqxvhkeJkA9NLu+Y2VXinPpBuG4lUgZKAJQQ/7rg38LXG/yggwNHXVUl2vLRRrt2dP+I7usEp00trSe84/hV2IMKvNB2xWfn3VN+H9hA3tgsNu+DY0S1fRJ8fQVVFdSxuEVvX4yxkmG06sbrfRroRH6rq0j9IsnabGVG/LKMnvWVd2yTbLxNwHENcOvwYHiL8l9mm7p+O58o22rw+LFxD8rfpuxGjWy2ecGhD1QbLRq9b47FQhIw== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB2668.namprd11.prod.outlook.com (2603:10b6:5:c7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 23:41:14 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5%6]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 23:41:14 +0000 From: Mike Ounsworth To: Ryan Sleevi , Russ Housley CC: LAMPS , Erik Andersen Thread-Topic: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension Thread-Index: AQHWuTb0bfM0bkcfUEG2GjeqUSCv/6nFB3aAgAAHOQCAABbskA== Date: Thu, 12 Nov 2020 23:41:13 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sleevi.com; dkim=none (message not signed) header.d=none;sleevi.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efe8b936-ff98-4549-caa4-08d887647149 x-ms-traffictypediagnostic: DM6PR11MB2668: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P9X9XA1R/DVFwZTTq0zy1MIcP0eXkbVqqoHG7N5+VTkPFkgAy4esi355Cb7LFl22EaM0PT9oGZInkuX+sFMLKFgjSjqlrw/EZ8vtZsU6gvW1aVx+hT+ggFWBzAVxQipxoOTROwUSvqMcIM21vy4zuXQ+hswm3NyjpX3FeGPYWiK9ctI0TaXDmi47oazLErtHyGUNFvuGj5C0SVF99nuUvR97Bf5ZHT9ApiW8vDA2Y52wnpr25rmPIfx6yTCoeSIj+8kw2g7vp3pybDCEPpUzkM8nfSNoCav56G99Dx+L0aplioCnycyxGOY+MP7oL6hLeJFZqIgZSa90+1IHAJfitg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(8936002)(110136005)(83380400001)(33656002)(66476007)(55016002)(76116006)(9686003)(316002)(64756008)(186003)(26005)(71200400001)(66556008)(478600001)(54906003)(66446008)(6506007)(7696005)(8676002)(2906002)(5660300002)(52536014)(86362001)(66946007)(4326008)(53546011); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ZDrZlQmGUHFwrYB84DALtAR+t2G726H9sv616hjd6cXjqEN6Zi/Zcl2wpFKTNTrlOniuUpOdcKaDSnTR2PjuK0KTENwm0fsJJEYOVuQkgLQdn1Kb1EjJrHKpUMwO9l1fUNbAM2Xqwd1rE4korQSI8Q3mm6IJQCkEFOL/wiq4b5biZTrpwCxoKi5iilsJs9DJC0xV8wJMNMbsUc2JyhYWkwlL/daBbN+x+ApxEBDkNGRJmhiqBhpDLov0nSx+2HBj/eFdZw05VY3Xwd27SqA/WOaQN83U2E3XTIouQe5R/9LC7EOQ7ge4zQAnDM/GSbRvf6dSCUpAVJi8xxJ+86rm39nFGDvLTF5829Kz0oWj3lgGnHCpZfBjL9/P+ODExkY8N2oSV9C7QtFkMPOuXa2AYQTWAH+rbey3xJgYCJpWCJBQEwo4g2Bh0Pg0pOWxUtZ3QZgBiKr6/PHdTb9PdDVGOYghH7MZlOo3Yu1R82YUzwg56b7vdkK1VAKfdv2NudBo8BeE8LuBKIIa4xNYx057E6O8BL+VwBM3fx60KLto2pSWR25jvjlrxFTvOitEh0A/Qy939tl6cVtyBTlbsilZlXbYB2CE1kVOwB/S1hTXSlWt2FahFMr2rRjTAN4C44pbNa7HBXwj3p3NpytkNmXoDA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: efe8b936-ff98-4549-caa4-08d887647149 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 23:41:13.9076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7CrDbR+vhZB9KKGTVpbPBufxlRchqPMfn0icTbmjbDOMslRUzEaHhwFQmyBRSzYjtciWcvqvXuidGJX6tfUjbKe/IeVWhRXGdrb8U4kseuE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2668 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Fri, 13 Nov 2020 09:03:26 -0800 Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 23:42:44 -0000 PiBDb25jcmV0ZWx5OiBJZiBhIGNlcnRpZmljYXRlIGxhY2tzIE9DU1Agb3IgQ1JMcyBpbi1iYW5k LCB3aGVyZSBpcyBpdCBnb2luZyB0byBmaW5kIHRoZSBpbmZvcm1hdGlvbj8NCg0KSeKAmW0gbm90 IGFuIE9DU1AgZXhwZXJ0LCBidXQgYSBjZXJ0aWZpY2F0ZSB3aXRob3V0IGFuIE9DU1AgQUlBIG1h eSBzdGlsbCBoYXZlIGFuIE9DU1AgcmVzcG9uc2Ugc3RhcGxlZCBpbiB0aGUgcHJvdG9jb2w/IEkg aGF2ZSBubyBwZXJzb25hbCBleHBlcmllbmNlIHdpdGggc3VjaCBhIGRlcGxveW1lbnQsIGJ1dCBJ IGNvdWxkIGltYWdpbmUgY2xvc2VkLW5ldHdvcmsgUEtJcyB3aGVyZSB0aGF0IG1ha2VzIHNlbnNl LiBBbiBpZC1jZS1ub1JldkF2YWlsIHR5cGUgY2VydCBleHRlbnNpb24gd291bGQgYWxsb3cgYW4g UlAgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBtYWxpY2lvdXNseSBvbWl0dGVkIE9DU1AgcmVzcG9u c2VzLCBhbmQgY2VydHMgdGhhdCBhcmUgbm90IGludGVuZGVkIHRvIGhhdmUgdGhlbS4NCg0KLS0t DQpNaWtlIE91bnN3b3J0aA0KU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0LCBFbnRydXN0DQoN CkZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUnlhbiBT bGVldmkNClNlbnQ6IE5vdmVtYmVyIDEyLCAyMDIwIDQ6MTAgUE0NClRvOiBSdXNzIEhvdXNsZXkg PGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KQ2M6IFJ5YW4gU2xlZXZpIDxyeWFuLWlldGZAc2xlZXZp LmNvbT47IExBTVBTIDxzcGFzbUBpZXRmLm9yZz47IEVyaWsgQW5kZXJzZW4gPGVyYUB4NTAwLmV1 Pg0KU3ViamVjdDogW0VYVEVSTkFMXVJlOiBbbGFtcHNdIFRoZSBpZC1jZS1ub1JldkF2YWlsIGV4 dGVuc2lvbg0KDQpXQVJOSU5HOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBFbnRy dXN0Lg0KRE8gTk9UIENMSUNLIGxpbmtzIG9yIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgdHJ1c3Qg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCk9uIFRodSwgTm92IDEyLCAyMDIwIGF0IDQ6 NDQgUE0gUnVzcyBIb3VzbGV5IDxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0K SXQncyBub3QgaW1tZWRpYXRlbHkgb2J2aW91cyB0aGUgdmFsdWUgcHJvcG9zaXRpb24gb2YgImFm ZmlybWF0aXZlbHkgYXNzZXJ0aW5nIG5vIiB2cyB0aGUgc3RhdHVzIHF1byBvZiAiZGVmaW5pdGl2 ZWx5IG5vdCBhc3NlcnRpbmcgYW55IGluZm9ybWF0aW9uIHNvdXJjZSIsIGFuZCB1bmRlciB3aGF0 IHByb2Nlc3NpbmcgbW9kZWwgYSBjbGllbnQgd291bGQgZmluZCBpdCB1c2VmdWwgb3IgaW1wb3J0 YW50IHRvIGRpc3Rpbmd1aXNoIHRoZXNlIGNhc2VzLg0KDQpUaGUgZGlmZmVyZW5jZSBpcyB0aGUg cHJvY2Vzc2luZyB0aW1lIGl0IHRha2VzIGZvciB0aGUgUlAgdG8gdHJ5IHRvIGZpbmQgaW5mb3Jt YXRpb24gd2hlbiB0aGUgQ0Ega25vd3MgaW4gYWR2YW5jZSB0aGF0IHRoZXJlIG5ldmVyIHdpbGwg YmUgYW55Lg0KDQpJJ20gc29ycnksIEkgdGhpbmsgeW91IGFuc3dlcmVkIGEgZGlmZmVyZW50IHF1 ZXN0aW9uIHRoYW4gSSB3YXMgYXNraW5nLCBzbyBJJ2xsIHRyeSB0byByZXBocmFzZSBpdCB1c2lu ZyB5b3VyIHJlc3BvbnNlLiBJJ20gbm90IGFza2luZyBhYm91dCAid2h5IHdvdWxkIHlvdSB1c2Ug c2hvcnRsaXZlZCBjZXJ0aWZpY2F0ZXMiLCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCB5 b3Ugc2VlIGFzIHRoZSBzdGVwcyB0aGUgUlAgdGFrZXMgdG8gInRyeSB0byBmaW5kIGluZm9ybWF0 aW9uIiwgaWYgbm8gcmVmZXJlbmNlcyB0byBzdWNoIGluZm9ybWF0aW9uIGFyZSBtYWRlIGF2YWls YWJsZSB0byB0aGUgUlAgd2l0aGluIHRoZSBjZXJ0aWZpY2F0ZS4NCg0KQ29uY3JldGVseTogSWYg YSBjZXJ0aWZpY2F0ZSBsYWNrcyBPQ1NQIG9yIENSTHMgaW4tYmFuZCwgd2hlcmUgaXMgaXQgZ29p bmcgdG8gZmluZCB0aGUgaW5mb3JtYXRpb24/DQoNCklzIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhl IGNsaWVudCB3aWxsIGJlIHBlcmZvcm1pbmcgTERBUCBkaXJlY3RvcnkgY2hlY2tzIGJhc2VkIG9u IHRoZSBETiBvZiB0aGUgY2VydCwgYXMgZW52aXNhZ2VkIGluIFguNTA5djE/DQpJcyB0aGUgYXNz dW1wdGlvbiB0aGF0IHRoZSBjbGllbnQgaXMgbG9jYWxseSBjb25maWd1cmVkIHRvIHN1cHBvcnQg c29tZSBsb2NhbCBjb25maWd1cmF0aW9uIHRoYXQgcG9pbnRzIHRvIGEgcmVwb3NpdG9yeSB3aXRo IHJldm9jYXRpb24/DQoNCkluIG9yZGVyIGZvciB0aGVyZSB0byBiZSBzdGVwcyB0aGF0IGFyZSBz a2lwcGVkLCB0aGVyZSBuZWVkcyB0byBiZSBhIHN0YXRlbWVudCBvZiB3aGF0IHN0ZXBzIGFyZSBw ZXJmb3JtZWQuIFdlIGNhbiAib2J2aW91c2x5IiBkaXNhYmxlIENSTHMgYW5kIE9DU1AgYnkgc2lt cGx5IG5vdCBwcm92aWRpbmcgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUsIHNv IEkgd2FzIGhvcGluZyB5b3UgY291bGQgYXJ0aWN1bGF0ZSB3aGF0IG90aGVyIHNvdXJjZXMgb2Yg aW5mb3JtYXRpb24gdGhhdCBtaWdodCBiZSB1c2VkIGJ5IGEgY2xpZW50IHdoZXJlIHN1Y2ggYW4g YWZmaXJtYXRpdmUgZXhwcmVzc2lvbiB3b3VsZCBiZSByZWxldmFudCBhbmQgbmVjZXNzYXJ5Lg0K From nobody Fri Nov 13 09:03:33 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1733A1033 for ; Thu, 12 Nov 2020 15:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=GOfBI9iH; dkim=pass (2048-bit key) header.d=entrust.com header.b=BP92wOyz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53ZCJKdpGgna for ; Thu, 12 Nov 2020 15:45:23 -0800 (PST) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333E83A1031 for ; Thu, 12 Nov 2020 15:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1605224723; x=1636760723; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=GOfBI9iHtFsKb72dnwHtRswIRhol3vfilgBAtmOSanQjn2nGUu7z5xmN /VPXZLlCcGOq8jauF7O2plDRkuT3ABHlebCRXXIUALxH+dZ1Em+ooBIIz vzJiDpXXJTdbL1pl0jRm78ZyFFVV6i5Gz79IkgWJuw1Z3cdsoFUu1O6Mw TEWILEVDiyqXKvZcN3K7yil4ODJ+7Sb8cpBxLoKN61gUyhDbHtq1urCmv 9jMkbyq5E1mp2iI+Pik+zqiy4jwYOPVvejotUc4HuysLBM1KY4/4I9RWM I4/eQp+lcQrECEBMbozPkKGyWfhzIfZYIwhefBZgeotYy7F0LFlysMAXA A==; IronPort-SDR: Z3QhQekZa6DndUe168zowox2CK98+CNecv+kzcOZnt+wgdHd+xLbwIh0lOd7NPlsuLTXjaEFUG KE9LmGK7hadQ== X-IronPort-AV: E=Sophos;i="5.77,473,1596517200"; d="scan'208";a="90742372" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 12 Nov 2020 17:45:22 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 12 Nov 2020 17:45:22 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 12 Nov 2020 17:45:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aN9JEyciziOpSmOkHXi1lUuLgNsvXHxeIwKTM0ouNqd5GCL/LYH0Mosi1DXOg6TCQRhT5MtVMcAfqAW3o1DBwft9fkyLG9WH8mOz/RUCdh+oYZKKBH/UnxpgFN6ZgJ/Qa+eRbmMKZ72Ew+lYbjYntLR9ConVbvEAKEZxwy0Hi6wsjDs+RJen2AUh/UCSrhjRu7NXp+UbtTQjwLESB9gEfY/RNxYSziU0eJ9QHWi5VjzeSQUkoPnAFaWVZly/mmv9Rr0j2CXfYRF8u+BvdUF6f0N70hbFqWwuf31aHWaow4UzLIZNtOoEQyDnKEqsb54dB5wqtbYe4/NlouBmue78rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=CGMQaR9VAdB9OIStzU5MNVAT22pNx537h8pysbr8CgDqtgk6Cv37lavjpGXUMyxnmpCh40zJrN21zX0Ai/qLCO+MvcIkYaDLJMhBUeSR6Z+DbBQN5W1sZD2jV726OuEk5B6X27ljf/Sbb5AhHz99tSMwaX/lYmF3BCGrqhH6qIafWBEotSXGpcU7swVxt5mldlpi+HebI4BLlkaNjsi3C87wS2TtzIDWNYTS0H3N1JyjzpcTpVjZvIlQE9tzU92nYKNBnWHmNOTIubk+EkctkLVXAfm5cRwU2gOnBZQ4TmeqwES9vOiP2jMeOWKn6/VhLG9gGW9NNFOmzKbR4/Tcgg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWQgIKeb9GbmrTRboVk7dL0RAZwBTgTLmZptxMmsDKs=; b=BP92wOyzGrgV4i9cPUN96XDairek1DEGq7NJAIvIX3xUnF2oK9/Qk+m0q88+mbaiV7UPGbxUP4aIrtrr312X7DM39s/WM3lbWDIRa3uU8b1fR+BgDwmFbwUxNULkhchTYuIc9y17khDt14FH/BJT8dlWuKMrgVH5j1NHEiNoCYDXtDKwJvbWldwV/YWsUJH9WqhTMImpfm5qPicrVtVUVnjjkvJQCagEq1xyN6oet7UwEFb0zZkhnFA38RpYeKx/kjGfb+aQPYQyXX2M2vKONGXDBnuiC4h1tu54cS8S8eMLn9aEzP9AY8KBz/oqZd/TzLIUavfuK8WD/AKMsfUPnA== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB2649.namprd11.prod.outlook.com (2603:10b6:5:ce::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 12 Nov 2020 23:45:20 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5%6]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 23:45:20 +0000 From: Mike Ounsworth To: Ryan Sleevi , Russ Housley CC: LAMPS , Erik Andersen Thread-Topic: [lamps] The id-ce-noRevAvail extension Thread-Index: Ada5TeCSYpcy77b3SGOY2Jm+ye/f+Q== Date: Thu, 12 Nov 2020 23:45:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sleevi.com; dkim=none (message not signed) header.d=none;sleevi.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66ccd23f-94ba-4ef6-8f3b-08d8876503f3 x-ms-traffictypediagnostic: DM6PR11MB2649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HAW7BOPGc65icPxQE0aLKxIdqzwYwu5X/NGW900Yp/DwiLXG0BJ0bNWwD8mzHubwqVKnbjcPNQFds96adx8ycvDDrJF6sW0xVj00Z5nbRaUDxHNfbzxf3GyvpCc7z2CvJ53zfxqh/wqL9+vDlYc8dLQk8I9Qt8inl5ymotBrDO3wf83RvPBbtVG/AdYhNIg//O+uelTez/d8SJp/MCbUSD2pWeU0QdraSowlpozxPS9pBaOTnpgEmJRMgS6otqt7wbpWilMoHCssATVcVnbPjGfg9RWwJk08QRnECkZ3C5/o1xxPEn+Q+gHCtD2orTVM9Be6Xzs31NcCBdufV9qy3w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(66946007)(26005)(54906003)(4326008)(8936002)(66476007)(110136005)(316002)(7696005)(53546011)(6506007)(9686003)(71200400001)(186003)(64756008)(8676002)(66556008)(66446008)(76116006)(2906002)(52536014)(5660300002)(86362001)(55016002)(478600001)(83380400001)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 8KC/KsAG35RVNPz51UD4qLvYSS3ceENzN+IbR5YjK0c5DQbwueEWNDDpnZdH4yhfrsXW63EdHVGjEZhRrPhbWECfXii0vF0ovqIvfBXgiAFiywTkAeZVhGcV4qh0hfaA9MOgpTBbTIMNAD5x132R5lAJnqXTceAjrp2L71wD+YCa/cTkIexGNaHSarRwHa+Pzu2+3aG3TMrWLo9dByOXl/LhT3xeuGsGUK6LsDti2urJZ+d8fsGZEeevLPkSNoJgZ7Yjp585yoVYkl2q8GavR0N1zF3wxUiFOGLiMu6wSOgnm4o3B2A+jXlr6bDCDols2k40w5J7cLKL6sNP7jznoVQo44HGezyarUnLNKQAPppNQhOAN3YfhtcaVOmndo9imX1NUurAexFv/IqLG2bpXqZONLw/eJ2O252xu+CXF8EoQXccCgrxkBF41JLBaX+EfYkYuh1Mny4dOlN1Dj5f/VNKXZWKhSyr3RHWBwyLAXzFgldg5axlr2YFSupZTBC4qFGfERPCpIEm1KX4tx9u7LwSAV9Wi/98HtrBsD30VS6KJSKkLjMx6P6NhCe9SGnw0WTfVpEwT1Rz3kvoxr9M35ju+3uttoHX/m6+SttY7mSiavm4uMIIRL/HetSguQNvAzRD+RXYqw9Fz+ZhZIy5aA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66ccd23f-94ba-4ef6-8f3b-08d8876503f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2020 23:45:19.9895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ak05LkT/aJXu1fvta+Kn5fBHm3HKU8ZEp4lBoKdN8GzeczQ6ebSdAmfinsJWvFQfSxIUJp8BQphtz9WewyIUggZRwGXwMhvhu87lsIIF5/0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2649 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Fri, 13 Nov 2020 09:03:26 -0800 Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2020 23:45:25 -0000 PiBDb25jcmV0ZWx5OiBJZiBhIGNlcnRpZmljYXRlIGxhY2tzIE9DU1Agb3IgQ1JMcyBpbi1iYW5k LCB3aGVyZSBpcyBpdCBnb2luZyB0byBmaW5kIHRoZSBpbmZvcm1hdGlvbj8NCg0KSeKAmW0gbm90 IGFuIE9DU1AgZXhwZXJ0LCBidXQgYSBjZXJ0aWZpY2F0ZSB3aXRob3V0IGFuIE9DU1AgQUlBIG1h eSBzdGlsbCBoYXZlIGFuIE9DU1AgcmVzcG9uc2Ugc3RhcGxlZCBpbiB0aGUgcHJvdG9jb2w/IEkg aGF2ZSBubyBwZXJzb25hbCBleHBlcmllbmNlIHdpdGggc3VjaCBhIGRlcGxveW1lbnQsIGJ1dCBJ IGNvdWxkIGltYWdpbmUgY2xvc2VkLW5ldHdvcmsgUEtJcyB3aGVyZSB0aGF0IG1ha2VzIHNlbnNl LiBBbiBpZC1jZS1ub1JldkF2YWlsIHR5cGUgY2VydCBleHRlbnNpb24gd291bGQgYWxsb3cgYW4g UlAgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBtYWxpY2lvdXNseSBvbWl0dGVkIE9DU1AgcmVzcG9u c2VzLCBhbmQgY2VydHMgdGhhdCBhcmUgbm90IGludGVuZGVkIHRvIGhhdmUgdGhlbS4NCg0KLS0t DQpNaWtlIE91bnN3b3J0aA0KU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0LCBFbnRydXN0DQoN CkZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUnlhbiBT bGVldmkNClNlbnQ6IE5vdmVtYmVyIDEyLCAyMDIwIDQ6MTAgUE0NClRvOiBSdXNzIEhvdXNsZXkg PGhvdXNsZXlAdmlnaWxzZWMuY29tPg0KQ2M6IFJ5YW4gU2xlZXZpIDxyeWFuLWlldGZAc2xlZXZp LmNvbT47IExBTVBTIDxzcGFzbUBpZXRmLm9yZz47IEVyaWsgQW5kZXJzZW4gPGVyYUB4NTAwLmV1 Pg0KU3ViamVjdDogW0VYVEVSTkFMXVJlOiBbbGFtcHNdIFRoZSBpZC1jZS1ub1JldkF2YWlsIGV4 dGVuc2lvbg0KDQpXQVJOSU5HOiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBFbnRy dXN0Lg0KRE8gTk9UIENMSUNLIGxpbmtzIG9yIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgdHJ1c3Qg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCk9uIFRodSwgTm92IDEyLCAyMDIwIGF0IDQ6 NDQgUE0gUnVzcyBIb3VzbGV5IDxtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0K SXQncyBub3QgaW1tZWRpYXRlbHkgb2J2aW91cyB0aGUgdmFsdWUgcHJvcG9zaXRpb24gb2YgImFm ZmlybWF0aXZlbHkgYXNzZXJ0aW5nIG5vIiB2cyB0aGUgc3RhdHVzIHF1byBvZiAiZGVmaW5pdGl2 ZWx5IG5vdCBhc3NlcnRpbmcgYW55IGluZm9ybWF0aW9uIHNvdXJjZSIsIGFuZCB1bmRlciB3aGF0 IHByb2Nlc3NpbmcgbW9kZWwgYSBjbGllbnQgd291bGQgZmluZCBpdCB1c2VmdWwgb3IgaW1wb3J0 YW50IHRvIGRpc3Rpbmd1aXNoIHRoZXNlIGNhc2VzLg0KDQpUaGUgZGlmZmVyZW5jZSBpcyB0aGUg cHJvY2Vzc2luZyB0aW1lIGl0IHRha2VzIGZvciB0aGUgUlAgdG8gdHJ5IHRvIGZpbmQgaW5mb3Jt YXRpb24gd2hlbiB0aGUgQ0Ega25vd3MgaW4gYWR2YW5jZSB0aGF0IHRoZXJlIG5ldmVyIHdpbGwg YmUgYW55Lg0KDQpJJ20gc29ycnksIEkgdGhpbmsgeW91IGFuc3dlcmVkIGEgZGlmZmVyZW50IHF1 ZXN0aW9uIHRoYW4gSSB3YXMgYXNraW5nLCBzbyBJJ2xsIHRyeSB0byByZXBocmFzZSBpdCB1c2lu ZyB5b3VyIHJlc3BvbnNlLiBJJ20gbm90IGFza2luZyBhYm91dCAid2h5IHdvdWxkIHlvdSB1c2Ug c2hvcnRsaXZlZCBjZXJ0aWZpY2F0ZXMiLCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgd2hhdCB5 b3Ugc2VlIGFzIHRoZSBzdGVwcyB0aGUgUlAgdGFrZXMgdG8gInRyeSB0byBmaW5kIGluZm9ybWF0 aW9uIiwgaWYgbm8gcmVmZXJlbmNlcyB0byBzdWNoIGluZm9ybWF0aW9uIGFyZSBtYWRlIGF2YWls YWJsZSB0byB0aGUgUlAgd2l0aGluIHRoZSBjZXJ0aWZpY2F0ZS4NCg0KQ29uY3JldGVseTogSWYg YSBjZXJ0aWZpY2F0ZSBsYWNrcyBPQ1NQIG9yIENSTHMgaW4tYmFuZCwgd2hlcmUgaXMgaXQgZ29p bmcgdG8gZmluZCB0aGUgaW5mb3JtYXRpb24/DQoNCklzIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhl IGNsaWVudCB3aWxsIGJlIHBlcmZvcm1pbmcgTERBUCBkaXJlY3RvcnkgY2hlY2tzIGJhc2VkIG9u IHRoZSBETiBvZiB0aGUgY2VydCwgYXMgZW52aXNhZ2VkIGluIFguNTA5djE/DQpJcyB0aGUgYXNz dW1wdGlvbiB0aGF0IHRoZSBjbGllbnQgaXMgbG9jYWxseSBjb25maWd1cmVkIHRvIHN1cHBvcnQg c29tZSBsb2NhbCBjb25maWd1cmF0aW9uIHRoYXQgcG9pbnRzIHRvIGEgcmVwb3NpdG9yeSB3aXRo IHJldm9jYXRpb24/DQoNCkluIG9yZGVyIGZvciB0aGVyZSB0byBiZSBzdGVwcyB0aGF0IGFyZSBz a2lwcGVkLCB0aGVyZSBuZWVkcyB0byBiZSBhIHN0YXRlbWVudCBvZiB3aGF0IHN0ZXBzIGFyZSBw ZXJmb3JtZWQuIFdlIGNhbiAib2J2aW91c2x5IiBkaXNhYmxlIENSTHMgYW5kIE9DU1AgYnkgc2lt cGx5IG5vdCBwcm92aWRpbmcgc3VjaCBpbmZvcm1hdGlvbiBpbiB0aGUgY2VydGlmaWNhdGUsIHNv IEkgd2FzIGhvcGluZyB5b3UgY291bGQgYXJ0aWN1bGF0ZSB3aGF0IG90aGVyIHNvdXJjZXMgb2Yg aW5mb3JtYXRpb24gdGhhdCBtaWdodCBiZSB1c2VkIGJ5IGEgY2xpZW50IHdoZXJlIHN1Y2ggYW4g YWZmaXJtYXRpdmUgZXhwcmVzc2lvbiB3b3VsZCBiZSByZWxldmFudCBhbmQgbmVjZXNzYXJ5Lg0K From nobody Fri Nov 13 09:03:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54F3A0D97 for ; Fri, 13 Nov 2020 07:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=YAaiORBw; dkim=pass (2048-bit key) header.d=entrust.com header.b=eALwK5xW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7abdAhZfUgyp for ; Fri, 13 Nov 2020 07:18:36 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 CA19C3A0D93 for ; Fri, 13 Nov 2020 07:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1605280715; x=1636816715; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=dBaXq0iClaqdHubfgWvf+IkDJ+ukmgZ+ICv+q85hNxA=; b=YAaiORBwUJqcDi/a1ASdW5P/boOY0ioyAZwo8OlQvLUvvww4mMQDU9Yg o65nnDr6+8HRADe4hfceSAWzu3i3l2GBtkXHr/YmTvF0B9tFp+h3AyeNA DZp/nmivofFPBQiG/wC/og0ys9KS54K/k0MmT5pdH6643avCijaILq79M 13/pnFZtIsBW/k9DvMeihtQqZNJrrCWY3rGl9xyXR9nYQ0qKJX++lvTKi sy/y5IMCul0yCS7M5lf9T9lFt0znkf99L3aREH74UNHDc9DF3cPUKw4IB B329++aMV7aqRkUbpTWPrdFmdhwCIKbOBByZcXYLsjZF2tHQSMlerCMIr Q==; IronPort-SDR: Fybzuc4zSi5lZV8tXkP9lQGKhCmVKbjrwuhl5sbZTxRmUJ300iYHtnZeOebpUuIs13To0AR6ya OhicxPl5UOVQ== X-IronPort-AV: E=Sophos;i="5.77,475,1596517200"; d="scan'208";a="23443701" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 13 Nov 2020 09:18:34 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 09:18:28 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 13 Nov 2020 09:18:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fjdh0BlTjGN0sZzibPcQ2ooWk017i1WBSKGGrBQXN69fg7QOx9lfEZMMRItBi/2Y+8/xCr9ETJ/h5Yv+TgQwVSoAflXNEqZYpKpPqa9NMNv4SSkyPL12qC6iM2iblhVJfxN0Rcia4ad2o4qRAw52GxB3rSBS33FstNOnjKgKiIkbQ8kAovSu5zdHX8ulY2MMvrej5lsFK7iPl/gNF1tGRje/GVv0BNItyhgqgM+oVsjMnbf8D4ElUsszjem1nYwzWnmoBX02W4ciiwJJ6Pi0DmD1bncxSqV9U9yn55yCpqbBBblaGTiYR8lL7TlnHLaSc4NO3E4bbbvCeG/ylSOcVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHySRDbsOUa0W2elp6fJg9vOvLG3h8/P8XDtW1cnZPY=; b=C9ZL0sg32FBHNUFWwNjOHnv5LSUngDJC3KyuoGG5KipKr/DiQaKt5KGkl2uo9GePMqPIuhGyInNeqUHzduuqCC/alVIVi/tkGIup+TuAtRBTjb/GBtIZhP/09pC4pdoUTNOtn0SkY4h9S49X4VydXAXJUlFTl7lahL7PCRCTtZTK/5tMxy5vvlHbnr4QPzlY15cwyOI4TnAqYZdMzhCNuH7/F+izWTvORCyEcJ/NdrLOOa7uP61NsUrWknTUSaj7CXreot2agiuvTh23uyYo3hJpazqlTbeO9Ws+QgyrGcy9zh0wMLsfnkpebNTNX2wv6V6XCLLoY84YQmzDCffyfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EHySRDbsOUa0W2elp6fJg9vOvLG3h8/P8XDtW1cnZPY=; b=eALwK5xWgS9QsglhcK8eRa6ACzzHkRalIz+IRpVvEPZaSC+C7f7QYPk1SiRl1v/f7bka5a8VLWnNmfs74FhWAb/1CJFRrTZRIucw94lB8CSuStJfe0AS2wUcQ5OcPEhxC22w3e/iOQ4J1eTIRBKCP75lTOOKS0HJQFujNTcaqFzLMxQDgRVjng/D8YmKnG9deLyiIAD+SHa3JTn+QB3rB5w9iVyS8t9a8kxIhlkmFKepj2UPHTwrEFAUzBk6baXhc0Aa5OeHHpvr0FFqHETRBk1HdYpoB0xMsYIFIL4qT3UzBe4ZH5rb35jTVCiPY6DA6bC/t694wm73J+UZ9Y+Ztg== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB4705.namprd11.prod.outlook.com (2603:10b6:5:2a9::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Fri, 13 Nov 2020 15:18:26 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::558e:bc0d:5192:51b5%6]) with mapi id 15.20.3541.025; Fri, 13 Nov 2020 15:18:26 +0000 From: Mike Ounsworth To: Russ Housley , Ryan Sleevi CC: LAMPS , Erik Andersen Thread-Topic: [lamps] The id-ce-noRevAvail extension Thread-Index: Ada50DSzBWxzgmpBTtmeTlIGe++dGQ== Date: Fri, 13 Nov 2020 15:18:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 728bf3b8-6ba6-454b-d8d8-08d887e75e4b x-ms-traffictypediagnostic: DM6PR11MB4705: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mQaxiJAHQKCzc2ixKeiWYyOnynKzYcsMNih+bQSAmGIi/invGjCHdEKCOQSqQxVcy3cMLcnOaYl+87XSV/84VKeA5HFtfD2u0Ca69UTfMGY+KeiZjnEfxk8v9YQbQmB2OsUXmbn6J8VUhcdHpZqdT4qBujk0Zzn/zNXYcVrND1p61m0JiqMd5cg2fc5NaV7pX0xa+buh7rruUKaVtzfNpwUollLESuyl2y4QDKcNiNj2m2+R+4+EDbIg6mKAAEpvfRQ4HWIhC54jtCARwcpVFtSkJO2XBz1cfaYcNA7zUOMEHlHcpZnuJp9vM3+Uleg55iwLwl6b23j6PLJlNm3zzw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(55016002)(8676002)(9686003)(71200400001)(86362001)(478600001)(4326008)(76116006)(7696005)(5660300002)(66556008)(66446008)(66476007)(66946007)(64756008)(110136005)(83380400001)(2906002)(33656002)(186003)(6506007)(8936002)(54906003)(52536014)(4744005)(26005)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: qDzJgAd1rgEa7nwBBRefVUqL9lb5Z37wjotvBESTy+KgU0qn1Hw9KfdrYGjvgnRU5eM3gkQJ89jjS0s5Z6orB33wBej46L3EpOoSMN+yWTyl4TbH9ZMr2RD9vJKvlTsU2jPzPTWzlRinkOKqSvTkRULWh/MTYq9b0Y+OPlctn6un5Bw+BAde/2IXVpwI168l8uu7+KTETL9h2VP7JGvMIqtsTmhuykmEsCOxKwCV8K3wXzzzB+FRjVlQJgnQOX4+8y5pdELXB6/iqajXuG/udSqpEqcKrnaaRB82hAqHwRb74FTPJ6KLEHAAmbPJV3VWykEdahhtX3fUaS0Yn8t7iButw0rezxtVPbcn0+AyjJkQKtG/HUt57g1b80f7iL3dKmkB5RoN6ZpZ1nI0w/Ds83RhllOcdY6KzvfdvqKAcNUYh6piAXEhW657LbaNZKhS7xXOUpKpF/ZMkYHGZ19IHrlf2BFxKyCfYN90iP7XwHltIBBOR1xNmVWHJb59n+Q7xXRcDFQRB0oMAsVm4DzQewFpnHl8G40CRnPDYmQhm20lf57ks9sxfTC17uZPmWL7EamR/V4m99jaA6FbeKLy0ScLPqFhsYCw3Er03hmfrfzQv84JQLyhaFbFtIIMMNbVTRMMqUUwwH2GwvQvC6laHA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 728bf3b8-6ba6-454b-d8d8-08d887e75e4b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2020 15:18:26.0970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YlxN/zGcfop72xN+zroRIgRPEyxa07WHxbfrahqI/S/WSh51hF0FCbk3aK36AUuSaw7iHmLUkSlgY766C9Hqcv0RO99dIJz5Ac3NrZSwg54= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4705 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Fri, 13 Nov 2020 09:03:26 -0800 Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 15:18:38 -0000 > I have heard about several application, not in the Web PKI, where a very = short lived certificate is being used. In one extreme case, a key is gener= ated, certified, used for one signature, and destroyed. I am also aware of a deployment like that; effectively creating one-time-us= e signing certificates by issuing them with a 60-second lifetime. (Whether = it's a good design or not is another question, but the system is very much = in use). --- Mike Ounsworth | Office: +1 (613) 270-2873 From nobody Fri Nov 13 09:05:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B683A0F4A for ; Fri, 13 Nov 2020 09:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5x5tH7XPKVy for ; Fri, 13 Nov 2020 09:05:00 -0800 (PST) Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) (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 F1F293A0EF9 for ; Fri, 13 Nov 2020 09:04:59 -0800 (PST) Received: by mail-pg1-f172.google.com with SMTP id h6so7570126pgk.4 for ; Fri, 13 Nov 2020 09:04:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oR7lxji2zEXPzVCoKJMKjer4qMH2nO7gMXhHWlNb/SI=; b=nMxhdZ0dulm9I9aR0TRRwoygAzzvba9+go3raWc/qMaVvGl3vsPXqYHC2yJ5J3v+vW BV9g4hJpUNp0cxGSsyoFP5BlIFVtwZXnOod/8s5mJMTxOuMLSS6d0vF8z+f/hJFx+LvR TVDrxsSt8ipAQSknxWETOHTAZ+QxxGfnGuk1JSL3RFl2wgOQen397qhGUjYyRQ/JMtjt bsh4lc87sEGfqQjQYurQYkyBL4S6ix+KbgWD0DZG+tB4z6r+81s8+UWu4zhDaNrjFUmM JINfVKfaYdLWb/glehcCDI+0k7sHV6YxCRBk5mYn/MhSpzsGy9C/VjiKLSRvteIZ9zNs PXRQ== X-Gm-Message-State: AOAM533YTWuBx7CHhvkeWZpN/WRd0uLkMl8hY4m5/16m7OU3nGt7hQpX pwsUlxNZiHNyvlS4UoE5JKkVEuq8fL4= X-Google-Smtp-Source: ABdhPJwoSSBg9Z5X1y79xEqCVxf7dgSHoZQy/ulWZQSqJjhAr+njrTYAcSONfPeObEKiklf6hcXlvw== X-Received: by 2002:a62:256:0:b029:18c:6905:d18d with SMTP id 83-20020a6202560000b029018c6905d18dmr2751378pfc.67.1605287098966; Fri, 13 Nov 2020 09:04:58 -0800 (PST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com. [209.85.210.182]) by smtp.gmail.com with ESMTPSA id n68sm10147305pfn.161.2020.11.13.09.04.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Nov 2020 09:04:58 -0800 (PST) Received: by mail-pf1-f182.google.com with SMTP id w14so8117623pfd.7 for ; Fri, 13 Nov 2020 09:04:58 -0800 (PST) X-Received: by 2002:a17:90b:1b52:: with SMTP id nv18mr4259594pjb.172.1605287098602; Fri, 13 Nov 2020 09:04:58 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> In-Reply-To: <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> From: Ryan Sleevi Date: Fri, 13 Nov 2020 12:04:47 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: Ryan Sleevi , Erik Andersen , LAMPS Content-Type: multipart/alternative; boundary="00000000000046632605b400077a" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 17:05:01 -0000 --00000000000046632605b400077a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 10:17 AM Russ Housley wrote: > I=E2=80=99m hoping to get you to describe a validation process - a set of= inputs, > an algorithm, and outputs - where this extension would result in a > meaningful difference compared to just omitting OCSP AIA and CRL DPs. In > order for this to be useful, I imagine there has to be some algorithm tha= t, > should this exist on PKCs, would produce a different output if all inputs > were the same, save for the existence of this extension. This is hopefull= y > a fairly basic question, but it=E2=80=99s vitally important to get a clea= r answer, > because it allows us to ask =E2=80=9Care there other ways to get the same= output=E2=80=9D > (e.g. the omission of CRL DPs and OCSP AIA). Whether you want to frame it > in terms of proceeding of RFC 5280 Section 6, or frame it in terms of > running code that folks implement today, I=E2=80=99m ambivalent, but it= =E2=80=99s essential > to discuss the desired output, since the claim is implicitly that there= =E2=80=99s > no way to accomplish this today, and the extension is the only way. > > > Some systems, especially ones with that use LDAP or X.500 Directory, look > there for CRLs even if there is not a CRLDP extension. This extension sa= ys > to not do so. > Thanks. I think we're finally making progress here. Can you point to any examples of implementations that (still) allow for this? I realize this was the dream of PKI in the late 90s/early 00s, but it seems very few, if any, implementations support this, and it also seems to be far outside the realm "Internet X.509", unless the thought is that the X.500 Global Directory is finally just around the corner. What is being described here, as with Rich's explanation, is, at its core, "someone configures something according to local policy". And that makes the proposal to use this extension, on PKCs, an extension to "Allow a remote system to override local policy". I don't believe that makes any sense at all, from a policy perspective. But I also don't think it makes a good argument as to the necessity or benefit, since in order for this extension to be useful, we already have to accept a priori the ability of the device owner or administrator to configure something via local policy. Since we're willing to entertain that yes, there's local policy involved, it seems to reason that this capability can also be addressed via local policy, without any such extension. As I mentioned to Michael, it's reasonable to ask "How could we get the same result, without the extension". And for the scenario you're raising here, it stands to reason that the mere act of *not configuring that local policy* is equally sufficient to address the need. Since the repository is tied to a specific CA certificate, it's equally easy to imagine two intermediates from the same (logical) root; one of the intermediates issues certificates with revocation details available, and local policy configures that directory URL, and the other intermediate issues these short-term certificates, and local policy configures no such directory URL. That solves the same problem, and leaving any security risks entirely up to local policy. I would oppose introducing this to PKCs, since the argument is to have a "standard method", but that makes no sense at all, because it's a standard method whose semantics only make sense according to local policy configuration. I don't believe there is any interoperability "gain" from having such an extension, given that it already depends on local policy. --00000000000046632605b400077a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 13, 2020 at 10:17 AM Russ= Housley <housley@vigilsec.com> wrote:
I=E2=80=99m hoping to get yo= u to describe a validation process - a set of inputs, an algorithm, and out= puts - where this extension would result in a meaningful difference compare= d to just omitting OCSP AIA and CRL DPs. In order for this to be useful, I = imagine there has to be some algorithm that, should this exist on PKCs, wou= ld produce a different output if all inputs were the same, save for the exi= stence of this extension. This is hopefully a fairly basic question, but it= =E2=80=99s vitally important to get a clear answer, because it allows us to= ask =E2=80=9Care there other ways to get the same output=E2=80=9D (e.g. th= e omission of CRL DPs and OCSP AIA). Whether you want to frame it in terms = of proceeding of RFC 5280 Section 6, or frame it in terms of running code t= hat folks implement today, I=E2=80=99m ambivalent, but it=E2=80=99s essenti= al to discuss the desired output, since the claim is implicitly that there= =E2=80=99s no way to accomplish this today, and the extension is the only w= ay.

Some systems, especi= ally ones with that use LDAP or X.500 Directory, look there for CRLs even i= f there is not a CRLDP extension.=C2=A0 This extension says to not do so.





--00000000000046632605b400077a-- From nobody Fri Nov 13 10:42:45 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB963A1026 for ; Fri, 13 Nov 2020 10:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 u3SkkW_DJT15 for ; Fri, 13 Nov 2020 10:42:42 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 6C6683A1027 for ; Fri, 13 Nov 2020 10:42:42 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id 79so9810011otc.7 for ; Fri, 13 Nov 2020 10:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XhkFqdr0gCZLYpGog4kfGSukvaMEfJ1Ppn5rXO15MG4=; b=g3vJC73I+dxvlGdUJdOlaWvINnIHlJDIXpME0+Ywi1JanQfBmuKuzp8ktmtSMEd1dq nOpiAgCdAvEOnuKUYBoVoXGab77Pr1PH1aZC1cnxKzIqCK2RRRRrX1BhYUtAXChMI5P1 A19gdlT02B77+Zz08bMDJkf1M4RWyTsDh6E3MsWw61Lfc7Z+WFoHkI5K61oiTzbPJKUo KQD33qipDGItYs7fnuRTnXrrWcC9jSzHelI8K/8SOIjSKSVMoUhW3uHVCqHliO+4e+EI NjaA96zcPtrpVblYzl58h3gN+MIii4HlioV0ONjm9d98OuB9NbDDQrl6Zjkw4O5SZCeD ZP8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XhkFqdr0gCZLYpGog4kfGSukvaMEfJ1Ppn5rXO15MG4=; b=iXmYDgWlZyNsZzDi8oKD4Jw+GcmMrmsu+MQ3X8Ug6rAAvM1qtW3IHNe2WpMmS00jhp mJqRtA7qG+lulh+qtBCuKEwRfL+aZk+GRwyBXWw8gXzT7zJRvptzp9K7fbnwIFr6Hi3r syU09GRkc/tagVzaEXr/sTTQO01QC2r2o06OANUPKvbkWVbmqDGeRhZ02FK9QQ0OiP2w KXy7yMSGCN2vq6zYwEnWif0LU0Xr9VvINi/XBL8EyVrVSq6eMLkrPbu6ALx4g8T67jke mnDtGTOI/jaSiMxUsHlrF+WP95PoiSsdTHHansa4gXhzwHR89GqVLDz6rR4qxbyOu06e E3KA== X-Gm-Message-State: AOAM533o8YA25bNwrh7dghXTsU3zSVAhul1ps36Wumu1FJQUWoDpfIp9 MmG/4dys1JNl/dnhzVwVkg+Ff9wOH+LktMV5isPIMpTShUmqIQ== X-Google-Smtp-Source: ABdhPJy62yRqiB2QY/ditgKjzEmC3H/a2DUo4KdGh1CmIqHz0QvFRscJDsOQ+Xp7MmttOkKpo0f+tCs/6YKnyHa/yNg= X-Received: by 2002:a9d:72c4:: with SMTP id d4mr2591249otk.149.1605292961831; Fri, 13 Nov 2020 10:42:41 -0800 (PST) MIME-Version: 1.0 References: <16255.1605219019@localhost> In-Reply-To: From: Jonathan Hammell Date: Fri, 13 Nov 2020 13:42:30 -0500 Message-ID: To: Russ Housley Cc: Michael Richardson , LAMPS Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 18:42:44 -0000 I support adoption of this draft. For reference, the ASN.1 module including GMAC in ISO/IEC 9797-3 specifies: is9797-3 OID ::= {iso standard message-authentication-codes(9797) part3(3)} id-gmac OID ::= {is9797-3 gmac(4)} GmacParameters ::= SEQUENCE { bcAlgo BlockAlgorithms, taglength INTEGER, noncelength INTEGER } where bcAlgo would specify AES-128, AES-192 or AES-256. Matching other algorithms in 9797-3, the nonce is assumed to be transmitted separately. However, I think the definition of GMACParameters in your I-D makes more sense. Best regards, Jonathan On Fri, Nov 13, 2020 at 9:12 AM Russ Housley wrote: > > > > > On Nov 12, 2020, at 5:10 PM, Michael Richardson wrote: > > > > Signed PGP part > > > > Tim Hollebeek wrote: > >> https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt > > > > > > > >> Please indicate by November 25th whether you support adoption of > >> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. > > > > Seems short and to the point. > > > > An example message in an appendix would be nice. > > Sure. That is something I can do in the next version. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Nov 13 10:46:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9133A1031 for ; Fri, 13 Nov 2020 10:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mPQoAXe4FwqC for ; Fri, 13 Nov 2020 10:46:20 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A903A102A for ; Fri, 13 Nov 2020 10:46:20 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0ADIgVaq023376; Fri, 13 Nov 2020 18:46:19 GMT 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=UzDUZ6Vsu/grHtb+6ohHtrHDCpFyi/vbM4R/3J9GS2c=; b=YRPVfG+l8/vdkLI+7h+vNY4k/R3UCwsDUo1eoySQX1SUcEonCTtRvkmRyEDLt3xjFogf NQ2oqbgR+4KeVS8jTOAzBBvaGQLLvMhOgD8LK9SbP1xwiBDBLc3z/14thqG7YPV46Kob saNizvsq7krvOFh1Jgi2m+QzZBjCzFUEHRK1N83u7tlFNR/NKDFdFfyZ7edUUUprnyym hib+eUO/Vznj1e7ULI3I/x9BYvU9nRAEox9jNqTijVE9x/sUIocX3HfZeZrJBre9vvQA E0d0QJyzieK9eTnd66DDFB23puRI8NBU3vhoz880plnBkdnKsBLQT/omksfIOeynq6LR BQ== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 34p2bs4y3c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 18:46:19 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0ADIXeTY009047; Fri, 13 Nov 2020 13:46:18 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint7.akamai.com with ESMTP id 34ssact8h8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Nov 2020 13:46:18 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Nov 2020 12:46:17 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Fri, 13 Nov 2020 12:46:17 -0600 From: "Salz, Rich" To: Ryan Sleevi , Russ Housley CC: LAMPS , Erik Andersen Thread-Topic: [lamps] The id-ce-noRevAvail extension Thread-Index: AQHWuQfg0vXIxFtUTkmz7h8sdnJ8A6nFYDmAgAAMMYCAAAc5AIABD3YAgAAJWgCAAAY8gIAAHgSA///IiIA= Date: Fri, 13 Nov 2020 18:46:17 +0000 Message-ID: <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@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/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_18C79F0797F3454FBB29CEA2E78106ADakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 adultscore=0 spamscore=0 mlxlogscore=904 phishscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-13_10:2020-11-13, 2020-11-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 mlxscore=0 clxscore=1015 suspectscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=822 phishscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011130120 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 18:46:22 -0000 --_000_18C79F0797F3454FBB29CEA2E78106ADakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaGVyZSwgYXMgd2l0aCBSaWNoJ3MgZXhwbGFu YXRpb24sIGlzLCBhdCBpdHMgY29yZSwgInNvbWVvbmUgY29uZmlndXJlcyBzb21ldGhpbmcgYWNj b3JkaW5nIHRvIGxvY2FsIHBvbGljeSIuIEFuZCB0aGF0IG1ha2VzIHRoZSBwcm9wb3NhbCB0byB1 c2UgdGhpcyBleHRlbnNpb24sIG9uIFBLQ3MsIGFuIGV4dGVuc2lvbiB0byAiQWxsb3cgYSByZW1v dGUgc3lzdGVtIHRvIG92ZXJyaWRlIGxvY2FsIHBvbGljeSIuDQoNCk5vLCBteSBleHBsYW5hdGlv biB3YXMgdG8gcG9pbnQgb3V0IHRoYXQgbm90IGFsbCBDQeKAmXMgdXNlZCBpbiB0aGUgV2ViUEtJ IHB1dCBPQ1NQIEFJQSBpbmZvcm1hdGlvbiBpbiB0aGUgY2VydHMgdGhleSBnZW5lcmF0ZS4NCg0K SSBzdXBwb3J0IGEgQ0EgYmVpbmcgYWJsZSB0byBkZWZpbml0aXZlbHkgc2F5IOKAnHdlIGRvbuKA mXQgcG9zdCBDUkwgb3IgT0NTUCBpbmZvcm1hdGlvbuKAnSBXaGV0aGVyIG9yIG5vdCBhbiBSUCB1 c2VzIHRoZSBleHRlbnNpb24gaXMsIG9mIGNvdXJzZSwgdXAgdG8gdGhlIFJQLiAgWW91IHNlZW0g dG8gYmUgdHJ5aW5nIHRvIHNob3cgdGhhdCB0aGlzIHByb3Bvc2VkIGV4dGVuc2lvbiBpcyBzb21l aG93IGRpZmZlcmVudCBmcm9tIHRoYXQuDQoNCg== --_000_18C79F0797F3454FBB29CEA2E78106ADakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjcxNTEzNTI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNjA2NDc2NTcyIDg4NjMyMTgzNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13 b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+V2hhdCBpcyBiZWluZyBkZXNjcmliZWQgaGVyZSwgYXMgd2l0aCBSaWNoJ3MgZXhwbGFuYXRp b24sIGlzLCBhdCBpdHMgY29yZSwmbmJzcDsmcXVvdDtzb21lb25lIGNvbmZpZ3VyZXMgc29tZXRo aW5nIGFjY29yZGluZyB0byBsb2NhbCBwb2xpY3kmcXVvdDsuIEFuZCB0aGF0IG1ha2VzIHRoZSBw cm9wb3NhbCB0byB1c2UgdGhpcyBleHRlbnNpb24sDQogb24gUEtDcywgYW4gZXh0ZW5zaW9uIHRv ICZxdW90O0FsbG93IGEgcmVtb3RlIHN5c3RlbSB0byBvdmVycmlkZSBsb2NhbCBwb2xpY3kmcXVv dDsuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLCBteSBl eHBsYW5hdGlvbiB3YXMgdG8gcG9pbnQgb3V0IHRoYXQgbm90IGFsbCBDQeKAmXMgdXNlZCBpbiB0 aGUgV2ViUEtJIHB1dCBPQ1NQIEFJQSBpbmZvcm1hdGlvbiBpbiB0aGUgY2VydHMgdGhleSBnZW5l cmF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IGEgQ0EgYmVpbmcgYWJsZSB0 byBkZWZpbml0aXZlbHkgc2F5IOKAnHdlIGRvbuKAmXQgcG9zdCBDUkwgb3IgT0NTUCBpbmZvcm1h dGlvbuKAnSBXaGV0aGVyIG9yIG5vdCBhbiBSUCB1c2VzIHRoZSBleHRlbnNpb24gaXMsIG9mIGNv dXJzZSwgdXAgdG8gdGhlIFJQLiZuYnNwOyBZb3Ugc2VlbSB0byBiZSB0cnlpbmcgdG8gc2hvdyB0 aGF0IHRoaXMgcHJvcG9zZWQgZXh0ZW5zaW9uIGlzIHNvbWVob3cgZGlmZmVyZW50DQogZnJvbSB0 aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_18C79F0797F3454FBB29CEA2E78106ADakamaicom_-- From nobody Fri Nov 13 11:06:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A763A1047 for ; Fri, 13 Nov 2020 11:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uhc2V1vXjgvA for ; Fri, 13 Nov 2020 11:06:23 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D413A1044 for ; Fri, 13 Nov 2020 11:06:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B8172300BA9 for ; Fri, 13 Nov 2020 14:06:20 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id McszXGSYhJAf for ; Fri, 13 Nov 2020 14:06:19 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id DF0FE300A48; Fri, 13 Nov 2020 14:06:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Fri, 13 Nov 2020 14:06:20 -0500 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <55E5AE27-E4FF-465D-8B29-559E7B4247BD@vigilsec.com> References: <16255.1605219019@localhost> To: Jonathan Hammell X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:06:25 -0000 I was unaware of the ISO/IEC 9797-3 OID, which seems to allow any block = cipher, and thus is not able to constrain the tag length based on the = specifics of that block cipher. Russ > On Nov 13, 2020, at 1:42 PM, Jonathan Hammell = wrote: >=20 > I support adoption of this draft. >=20 > For reference, the ASN.1 module including GMAC in ISO/IEC 9797-3 = specifies: > is9797-3 OID ::=3D {iso standard message-authentication-codes(9797) = part3(3)} > id-gmac OID ::=3D {is9797-3 gmac(4)} > GmacParameters ::=3D SEQUENCE { > bcAlgo BlockAlgorithms, > taglength INTEGER, > noncelength INTEGER > } >=20 > where bcAlgo would specify AES-128, AES-192 or AES-256. Matching > other algorithms in 9797-3, the nonce is assumed to be transmitted > separately. >=20 > However, I think the definition of GMACParameters in your I-D makes = more sense. >=20 > Best regards, > Jonathan >=20 > On Fri, Nov 13, 2020 at 9:12 AM Russ Housley = wrote: >>=20 >>=20 >>=20 >>> On Nov 12, 2020, at 5:10 PM, Michael Richardson = wrote: >>>=20 >>> Signed PGP part >>>=20 >>> Tim Hollebeek wrote: >>>> = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt= >>>=20 >>>=20 >>>=20 >>>> Please indicate by November 25th whether you support adoption of >>>> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. >>>=20 >>> Seems short and to the point. >>>=20 >>> An example message in an appendix would be nice. >>=20 >> Sure. That is something I can do in the next version. >>=20 >> Russ >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Nov 13 11:12:27 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE8C3A1064 for ; Fri, 13 Nov 2020 11:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dNWULoKDdUH for ; Fri, 13 Nov 2020 11:12:25 -0800 (PST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (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 5E41C3A1065 for ; Fri, 13 Nov 2020 11:12:25 -0800 (PST) Received: by mail-pl1-f173.google.com with SMTP id d3so4997142plo.4 for ; Fri, 13 Nov 2020 11:12:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UAylr4mWejY1WgsEFycsvnxQmb9EZAdgnKhkci24W4k=; b=PFSulQNfMaTYe1/6QvVJtG76iygxB4VuoQdyvy5Ws7l2Mw8nqY+Dt+nUhChFuRJ41K FdlBjZOACzyuJzmFmsIVuJ/K9lWqBZux8DI8qdyK0YqkrBwSD1dfGWlTEqTXYwh/dRUg Hppvz/IlEgr+tRGkEDZRvISBfSRis+BbzvfrMz5qa1BrXumz1jv9G9jVveSjIaS2zudX dK/Jwlk1nxU+65uXZfUybSKYVm9YraP9l9HY+zjWD/LnMacGzKaF8W72GDlU24z1mL3E l7vrotcYFPvbktgF/On+6GywnLVEdtIXB988fJnWCsneyPnbC2bO7MDmp9GzJsYJTnOo WPig== X-Gm-Message-State: AOAM5329Vi167T4TFXV2/yiFdH9PAtbJ+eiucs8yYQINz5nnFY2WNeBn aL69YJe9OdcZD1nr2owj5pW9mm2yrAk= X-Google-Smtp-Source: ABdhPJz821WwUsYdPZR9ybRYygkxr9Lt//X3631NvMjXZFvHZf9fBBKCxvolvZux/EatkIKykrig1Q== X-Received: by 2002:a17:902:d346:b029:d7:de:91fe with SMTP id l6-20020a170902d346b02900d700de91femr3399154plk.27.1605294744129; Fri, 13 Nov 2020 11:12:24 -0800 (PST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com. [209.85.210.178]) by smtp.gmail.com with ESMTPSA id w63sm10598738pfc.120.2020.11.13.11.12.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Nov 2020 11:12:23 -0800 (PST) Received: by mail-pf1-f178.google.com with SMTP id c20so8420724pfr.8 for ; Fri, 13 Nov 2020 11:12:23 -0800 (PST) X-Received: by 2002:a63:6981:: with SMTP id e123mr3281188pgc.364.1605294743745; Fri, 13 Nov 2020 11:12:23 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> In-Reply-To: <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> From: Ryan Sleevi Date: Fri, 13 Nov 2020 14:12:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Ryan Sleevi , Russ Housley , LAMPS , Erik Andersen Content-Type: multipart/alternative; boundary="000000000000f5f96305b401cef3" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:12:27 -0000 --000000000000f5f96305b401cef3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 13, 2020 at 1:46 PM Salz, Rich wrote: > > - What is being described here, as with Rich's explanation, is, at its > core, "someone configures something according to local policy". And th= at > makes the proposal to use this extension, on PKCs, an extension to "Al= low a > remote system to override local policy". > > > > No, my explanation was to point out that not all CA=E2=80=99s used in the= WebPKI > put OCSP AIA information in the certs they generate. > I'm not sure why you're referencing Web PKI - I certainly haven't - and I'm not sure what you're trying to highlight that is different from what I said= ? We can certainly talk about why this is beyond useless and borderline harmful for Web PKI, but I saw that as a distraction. I'm more interested in understanding how this fits into an RFC 5280 processing model, and how that aligns with running code. To be clear, when i say running code, I'm not restricting this to Web PKI. I'm trying to distinguish from the abstract notion of PKI as tied to an X.500 directory, which few have actually implemented, and fewer still use. To your explanation: Yes, there are CAs that provide OCSP that don't place it in certificates. My question has been to figure out where and how that information is reaching RPs, since the purpose of this extension is to say RPs should ignore that information. To wit, we've identified local policy and configuration as an answer, which your previous reply I think uncategorically shows. If that's not the case, I'm hoping you can explain where else this information comes from, since we agree that it's not the certificate. > I support a CA being able to definitively say =E2=80=9Cwe don=E2=80=99t p= ost CRL or OCSP > information=E2=80=9D Whether or not an RP uses the extension is, of cours= e, up to > the RP. You seem to be trying to show that this proposed extension is > somehow different from that. > Is your point, then, that this extension should be present, but not affect any processing whatsoever by the RP, in terms of RFC 5280 processing? If so, what is the point and value to putting something in for RPs that RPs cannot and do not use? If you see RPs using this somehow to affect behavior, then again, I'd ask you to clarify what behavior you'd like to see changed as a result of the presence of this extension. That would at least allow a meaningful exploration in how you can potentially already achieve that behavior, without needing to "standardize" yet another way to accomplish the same thing. [1] [1] https://xkcd.com/927/ > --000000000000f5f96305b401cef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • What is being described here, as with Rich's explanation, is, = at its core,=C2=A0"someone configures something according to local pol= icy". And that makes the proposal to use this extension, on PKCs, an extension to "Allow a remote system to override local pol= icy".

=C2=A0

No, my explanation was to point out that not all CA= =E2=80=99s used in the WebPKI put OCSP AIA information in the certs they ge= nerate.


I= 'm not sure why you're referencing Web PKI - I certainly haven'= t - and I'm not sure what you're trying to highlight that is differ= ent from what I said?

We can certainly talk about = why this is beyond useless and borderline harmful for Web PKI, but I saw th= at as a distraction. I'm more interested in understanding how this fits= into an RFC 5280 processing model, and how that aligns with running code. = To be clear, when i say running code, I'm not restricting this to Web P= KI. I'm trying to distinguish from the abstract notion of PKI as tied t= o an X.500 directory, which few have actually implemented, and fewer still = use.

To your explanation: Yes, there are CAs that = provide OCSP that don't place it in certificates. My question has been = to figure out where and how that information is reaching RPs, since the pur= pose of this extension is to say RPs should ignore that information. To wit= , we've identified local policy and configuration as an answer, which y= our previous reply I think uncategorically shows. If that's not the cas= e, I'm hoping you can explain where else this information comes from, s= ince we agree that it's not the certificate.
=C2=A0

I support a CA being able to definitively say =E2=80= =9Cwe don=E2=80=99t post CRL or OCSP information=E2=80=9D Whether or not an= RP uses the extension is, of course, up to the RP.=C2=A0 You seem to be tr= ying to show that this proposed extension is somehow different from that.


Is your point, then, that this extension should be present, but not affe= ct any processing whatsoever by the RP, in terms of RFC 5280 processing? If= so, what is the point and value to putting something in for RPs that RPs c= annot and do not use?=C2=A0

If you see RPs using t= his somehow to affect behavior, then again, I'd ask you to clarify what= behavior you'd like to see changed as a result of the presence of this= extension. That would at least allow a meaningful exploration in how you c= an potentially already achieve that behavior, without needing to "stan= dardize" yet another way to accomplish the same thing. [1]

<= /p>

--000000000000f5f96305b401cef3-- From nobody Fri Nov 13 11:26:15 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AED3A109D for ; Fri, 13 Nov 2020 11:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nT05kNe_p3oW for ; Fri, 13 Nov 2020 11:26:11 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::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 163E73A10A2 for ; Fri, 13 Nov 2020 11:26:10 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id k19so2943339oic.12 for ; Fri, 13 Nov 2020 11:26:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=khr4lKXh9n3PFWEJK8me5seE7GIPkhWRVTXxDYagOyI=; b=DJ8ag6UiAPa/KKKWh3Hu0/oLSJuSHQU75KGA4koPFUKvd4TgNAwZ3cg0g2LJsHy0y/ QqVp9KB2wSob0gaZIMiBTNWs1vDl2eB+qPRunG8vLchlxvRSS+bnK0ctBr7Fj5eVmHBf BysEDdvq/6G9Ji4UWyb895HXAdrGiQlE85I8UaabzeCCIm7cIEQzzn0QDCxNUMj161Ba anVQHjgYWjQBJIpoiMy9LgoI5Pl4Hj8USh5xxirTWOfrxk/7oWd8vfDw9tOVmLsCcb6d E/BtoRTGKHbFxbu81Degn6Sy/cA8QGvk+5+S/rOpizhd7/2FJUmvqO5oNRLxxiYF6bGO c6kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=khr4lKXh9n3PFWEJK8me5seE7GIPkhWRVTXxDYagOyI=; b=IOO8XXO9go70lPZsZLdV2mVvx840s8kN9ZVzrpW2oam9/zeH2KCcd7uWuAlwG2YOfa kmZDy7LKwVY/nq5uBdmX74+dgrQxJThu9xsQgF2fYAWhSGlBX/fASyfUDduv+Z7TwVFt RlP6J9XCgifsoCVlWOSTYIoKoHCxBHBr0lJN8OEhz4IaR2zF4mxo0H/Ak6NCg5+VL7R/ cffO34A1OIH6rs3VUkCjsBXvORqzjacqks18M0r3MG7YDNk1x5YTZT1uyRRWGjdm6yWA /bgpVKRQuS1VgEmFGjei5YwBtrAjfSuOjqp8BsSFF2sMEdwHa1y+/Nn+s9s9zjQ+JLSN VZWA== X-Gm-Message-State: AOAM532rbmTmJk5+AaA1vqovh6SrbhPuYTGQh0c+yVwntQ+4lfH3URI5 cP8IPz+xRSAbVsMHHYP6UkeqHi3njEY/nZUPnpcRXl6qfGqLlA== X-Google-Smtp-Source: ABdhPJzhbrejoqYjX9vZATUKTFNb2166Z7qICvMMhTvtOil/8rjTeQAhaR0Yj+jtSDUj96iyF+MEodbclCm9CsYn180= X-Received: by 2002:aca:88b:: with SMTP id 133mr2432561oii.143.1605295569286; Fri, 13 Nov 2020 11:26:09 -0800 (PST) MIME-Version: 1.0 References: <16255.1605219019@localhost> <55E5AE27-E4FF-465D-8B29-559E7B4247BD@vigilsec.com> In-Reply-To: <55E5AE27-E4FF-465D-8B29-559E7B4247BD@vigilsec.com> From: Jonathan Hammell Date: Fri, 13 Nov 2020 14:25:57 -0500 Message-ID: To: Russ Housley Cc: LAMPS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:26:13 -0000 On Fri, Nov 13, 2020 at 2:06 PM Russ Housley wrote: > > I was unaware of the ISO/IEC 9797-3 OID, which seems to allow any block c= ipher, and thus is not able to constrain the tag length based on the specif= ics of that block cipher. That is true that 9797-3 does not constrain the tag length based on the block cipher. In the normative text for GMAC, it states "GMAC can be used with any block cipher from ISO/IEC 18033-3 that has a block length of 128 bits. The resulting MAC is t bits long, where t is a multiple of 8 and satisfies 64 =E2=89=A4 t =E2=89=A4 128." Jonathan > > On Nov 13, 2020, at 1:42 PM, Jonathan Hammell = wrote: > > > > I support adoption of this draft. > > > > For reference, the ASN.1 module including GMAC in ISO/IEC 9797-3 specif= ies: > > is9797-3 OID ::=3D {iso standard message-authentication-codes(9797) par= t3(3)} > > id-gmac OID ::=3D {is9797-3 gmac(4)} > > GmacParameters ::=3D SEQUENCE { > > bcAlgo BlockAlgorithms, > > taglength INTEGER, > > noncelength INTEGER > > } > > > > where bcAlgo would specify AES-128, AES-192 or AES-256. Matching > > other algorithms in 9797-3, the nonce is assumed to be transmitted > > separately. > > > > However, I think the definition of GMACParameters in your I-D makes mor= e sense. > > > > Best regards, > > Jonathan > > > > On Fri, Nov 13, 2020 at 9:12 AM Russ Housley wro= te: > >> > >> > >> > >>> On Nov 12, 2020, at 5:10 PM, Michael Richardson wrote: > >>> > >>> Signed PGP part > >>> > >>> Tim Hollebeek wrote: > >>>> https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-= 00.txt > >>> > >>> > >>> > >>>> Please indicate by November 25th whether you support adoption of > >>>> draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. > >>> > >>> Seems short and to the point. > >>> > >>> An example message in an appendix would be nice. > >> > >> Sure. That is something I can do in the next version. > >> > >> Russ > >> > >> _______________________________________________ > >> Spasm mailing list > >> Spasm@ietf.org > >> https://www.ietf.org/mailman/listinfo/spasm > From nobody Fri Nov 13 11:29:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55C3A0E13 for ; Fri, 13 Nov 2020 11:29:58 -0800 (PST) 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 tsRiYkiX_DE8 for ; Fri, 13 Nov 2020 11:29:56 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::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 C37023A0DD3 for ; Fri, 13 Nov 2020 11:29:56 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kdeld-000mf7-Lc; Fri, 13 Nov 2020 20:29:53 +0100 Date: Fri, 13 Nov 2020 20:29:53 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Alexey Melnikov cc: LAMPS WG In-Reply-To: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> Message-ID: References: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [lamps] Proposal to adopt "Guidance on End-to-End E-mail Security" (draft-dkg-lamps-e2e-mail-guidance-00) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 19:29:58 -0000 +1 -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Tue, 10 Nov 2020, Alexey Melnikov wrote: > Hi all, > > I would like to propose that this document to be adopted by LAMPS. It will be > a dependency for the Header Protection draft and I think 2 drafts have > complementary scopes. > > Best Regards, > > Alexey > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Fri Nov 13 13:14:10 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3323A0A25 for ; Fri, 13 Nov 2020 13:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUedxgFDYA30 for ; Fri, 13 Nov 2020 13:14:06 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DB93A0A0B for ; Fri, 13 Nov 2020 13:14:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2BC99300B6A for ; Fri, 13 Nov 2020 16:14:03 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hKoQHgdOLfiT for ; Fri, 13 Nov 2020 16:14:01 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 2B85C300A48; Fri, 13 Nov 2020 16:14:01 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <9510208E-6E71-4254-A701-E077AFABA4F2@akamai.com> Date: Fri, 13 Nov 2020 16:14:02 -0500 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <9D47A01A-4089-4F6F-8D90-907A878010ED@vigilsec.com> References: <16255.1605219019@localhost> <9510208E-6E71-4254-A701-E077AFABA4F2@akamai.com> To: Michael Richardson , Rich Salz X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 21:14:08 -0000 Here is my proposed addition for the Example. Please let me know if it = does not meet your needs. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D Appendix: AuthenticatedData Example This example shows the establishment of an AES-256 key-encryption key to distribute the AES-128-GMAC content-authentication key. The content-authentication key is encrypted using AES-256-KEYWRAP. Thus, any party in possession of the key-encryption key could have produced the autenticated message. The recipient only knows that the message was produced by one of those parties. The AES-256 key-encryption key, in hexadecimal: 0b4db8bfae5d202c2dffaa6746658c7edf7a2c100fe8c8a74fc198b2cd9b7419 The identifier assigned to the key-encryption key is: fb6f2b3952fd7449d298f68aa4bcd94d The date used with this identifier is: 20201110120000Z The DER encoding of the AuthenticatedData encapsulated in the ContentInfo produces 289 octets, which are shown in hexadecimal: 3082011d060b2a864886f70d0109100102a082010c308201080201003151a24f 02010430230410fb6f2b3952fd7449d298f68aa4bcd94d180f32303230313131 303132303030305a300b060960864801650304012d04180cc1b55b29628000d7 005dc34b7e4ca2dc6735d53ae4def1301b0609608648016503040109300e040c bd4fecfd737d29e5419f307ea10b0609608648016503040201302b06092a8648 86f70d010701a01e041c5468697320697320736f6d652073616d706c6520636f 6e74656e742ea24b301806092a864886f70d010903310b06092a864886f70d01 0701302f06092a864886f70d01090431220420c875df2a4210704a9edddbb6df cc870471168f904d183318bbf184ac0b045e53040c86e90edca0be9fd74dd59c 37 Decoding this ASN.1 structure gives: 0 285: SEQUENCE { 4 11: OBJECT IDENTIFIER authData (1 2 840 113549 1 9 16 1 2) 17 268: [0] { 21 264: SEQUENCE { 25 1: INTEGER 0 28 81: SET { 30 79: [2] { 32 1: INTEGER 4 35 35: SEQUENCE { 37 16: OCTET STRING : FB 6F 2B 39 52 FD 74 49 D2 98 F6 8A A4 BC D9 4D 55 15: GeneralizedTime 10/11/2020 12:00:00 GMT : } 72 11: SEQUENCE { 74 9: OBJECT IDENTIFIER : aes256-wrap (2 16 840 1 101 3 4 1 45) : } 85 24: OCTET STRING : 0C C1 B5 5B 29 62 80 00 D7 00 5D C3 4B 7E 4C A2 : DC 67 35 D5 3A E4 DE F1 : } : } 111 27: SEQUENCE { 113 9: OBJECT IDENTIFIER : aes128-GMAC (2 16 840 1 101 3 4 1 9) 124 14: SEQUENCE { 126 12: OCTET STRING BD 4F EC FD 73 7D 29 E5 41 9F 30 7E : } : } 140 11: [1] { 142 9: OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1) : } 153 43: SEQUENCE { 155 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 166 30: [0] { 168 28: OCTET STRING 'This is some sample content.' : } : } 198 75: [2] { 200 24: SEQUENCE { 202 9: OBJECT IDENTIFIER : contentType (1 2 840 113549 1 9 3) 213 11: SET { 215 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } : } 226 47: SEQUENCE { 228 9: OBJECT IDENTIFIER : messageDigest (1 2 840 113549 1 9 4) 239 34: SET { 241 32: OCTET STRING : C8 75 DF 2A 42 10 70 4A 9E DD DB B6 DF CC 87 04 : 71 16 8F 90 4D 18 33 18 BB F1 84 AC 0B 04 5E 53 : } : } : } 275 12: OCTET STRING 86 E9 0E DC A0 BE 9F D7 4D D5 9C 37 : } : } : } The authenticated content is: 'This is some sample content.' From nobody Fri Nov 13 13:37:40 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4663A0CB9 for ; Fri, 13 Nov 2020 13:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Is7_tUg1Sy7g for ; Fri, 13 Nov 2020 13:37:37 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DBD3A0CB7 for ; Fri, 13 Nov 2020 13:37:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7EF27389D2; Fri, 13 Nov 2020 16:38:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HyrLrCD41OJM; Fri, 13 Nov 2020 16:38:13 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1128E389D0; Fri, 13 Nov 2020 16:38:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D6B2A375; Fri, 13 Nov 2020 16:37:34 -0500 (EST) From: Michael Richardson To: Russ Housley cc: Rich Salz , LAMPS In-Reply-To: <9D47A01A-4089-4F6F-8D90-907A878010ED@vigilsec.com> References: <16255.1605219019@localhost> <9510208E-6E71-4254-A701-E077AFABA4F2@akamai.com> <9D47A01A-4089-4F6F-8D90-907A878010ED@vigilsec.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2020 21:37:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > Here is my proposed addition for the Example. Please let me know if = it > does not meet your needs. Looks okay to me. I have a preference to base-64 encode the DER, because I think it's easier for people to decode that. I decode to something equivalent with "xxd -r -p n4 | openssl asn1parse -in -inform der" I'm curious what ASN1 dumper you are using? And wasn't the IETF april-1 standard PSK "makemetastegoat"? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+u/J4ACgkQgItw+93Q 3WUygwf+L229iW2iZqE84aWDWlWMtSd19RdHMZW4lDeso1LGHk4jd1M+67Kmr8Ei rbJt2VjQaAo58MTkVfJG94Xa0lFBCNdQYl68pUn5YZkdn3WKHqBTtBs5hsZgjrUU y2PEwiIS9MJTGFR0KaNQF5vnm3oAd2H42xBT/PnoDpnYYyirBPXVWEeRA4pLby4D MS+ACvHQVqCQZaZRdj9wwY2xRlDHSSsUC/6nqVLhatk5TmuST5Unf5sGQayQS780 gf7kIN6M51+ZOP8VURG0X2yI3EmJIztSXwrP50Sv+bWC9MKPScbHIKr4OytC6dKt TKmTWgFKgnyyOihlbswsDI+pTA9g8g== =oRm7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 13 22:26:52 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8556B3A11FC for ; Fri, 13 Nov 2020 22:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-OI9xhg_enr for ; Fri, 13 Nov 2020 22:26:50 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AF93A11FB for ; Fri, 13 Nov 2020 22:26:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7B7D7300B2F for ; Sat, 14 Nov 2020 01:26:47 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id popfkp6Z5paH for ; Sat, 14 Nov 2020 01:26:46 -0500 (EST) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id C227C300AA4; Sat, 14 Nov 2020 01:26:45 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: <16749.1605303454@localhost> Date: Sat, 14 Nov 2020 01:26:47 -0500 Cc: LAMPS , Rich Salz Content-Transfer-Encoding: quoted-printable Message-Id: <2E099CD5-88F6-4BE5-B556-F5C0B3C0103D@vigilsec.com> References: <16255.1605219019@localhost> <9510208E-6E71-4254-A701-E077AFABA4F2@akamai.com> <9D47A01A-4089-4F6F-8D90-907A878010ED@vigilsec.com> <16749.1605303454@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 06:26:52 -0000 I used dumpasn1 from Peter Gutmann: https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c https://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg Russ > On Nov 13, 2020, at 4:37 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Russ Housley wrote: >> Here is my proposed addition for the Example. Please let me know if = it >> does not meet your needs. >=20 > Looks okay to me. > I have a preference to base-64 encode the DER, because I think it's = easier > for people to decode that. >=20 > I decode to something equivalent with > "xxd -r -p n4 | openssl asn1parse -in -inform der" >=20 > I'm curious what ASN1 dumper you are using? >=20 > And wasn't the IETF april-1 standard PSK "makemetastegoat"? >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 From nobody Sat Nov 14 07:57:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135833A09CD for ; Sat, 14 Nov 2020 07:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 d4q54Uvrjiiv for ; Sat, 14 Nov 2020 07:57:18 -0800 (PST) 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 57FE73A00E3 for ; Sat, 14 Nov 2020 07:57:18 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AEFqO09016780; Sat, 14 Nov 2020 15:57:18 GMT 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=TBUr3y8+rRM7Y/1j/KAISqvHv9UaNVTOZjlRdGBIsaY=; b=JNArhVHSvcGN9qA6j2K/NH10kdfF5IMmhI3SsRCVSTMaNbu3Dz+8He31QFKbRmsXtKqN GLKuliuc61exYTnO31JJmIigbwgIkozcGfr/3eFa8CsjX3LWgBju4UJp7ceIViSaKPOv o5z0kTU1+VRA9XcK5ffzpmxhuZXcNFmnaOCR2DkNkAfrKvm0RdT4i+xydfssfgwF87e9 n6nvhVZZ4XLgqnWx1bSlIDJ+zS1d61ZQTVi4rkrBDL083sRlEda35L4lHBAakKdzFqw0 UmNR9etd8dwC8++uP+f0UtwlTsd0fRRaf5NzaL60SewaoxG2iF1uO5R2Vxv/twPhjDiM Ig== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34t85r7277-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Nov 2020 15:57:17 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AEFn4QD024273; Sat, 14 Nov 2020 10:57:17 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint8.akamai.com with ESMTP id 34tbf1hsvp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 14 Nov 2020 10:57:16 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 14 Nov 2020 09:57:15 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Sat, 14 Nov 2020 09:57:16 -0600 From: "Salz, Rich" To: Ryan Sleevi CC: Russ Housley , LAMPS , Erik Andersen Thread-Topic: [lamps] The id-ce-noRevAvail extension Thread-Index: AQHWuQfg0vXIxFtUTkmz7h8sdnJ8A6nFYDmAgAAMMYCAAAc5AIABD3YAgAAJWgCAAAY8gIAAHgSA///IiICAAFsTgIABB/KA Date: Sat, 14 Nov 2020 15:57:15 +0000 Message-ID: <45D17BD8-263E-4B51-B77F-7B2E02B80B3D@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_45D17BD8263E4B51B77F7B2E02B80B3Dakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-14_07:2020-11-13, 2020-11-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011140105 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-14_07:2020-11-13, 2020-11-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 bulkscore=0 clxscore=1015 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011140105 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 15:57:20 -0000 --_000_45D17BD8263E4B51B77F7B2E02B80B3Dakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSdtIG5vdCBzdXJlIHdoeSB5b3UncmUgcmVmZXJlbmNpbmcgV2ViIFBLSSAtIEkgY2Vy dGFpbmx5IGhhdmVuJ3QgLSBhbmQgSSdtIG5vdCBzdXJlIHdoYXQgeW91J3JlIHRyeWluZyB0byBo aWdobGlnaHQgdGhhdCBpcyBkaWZmZXJlbnQgZnJvbSB3aGF0IEkgc2FpZD8NCg0KWW914oCZcmUg cmlnaHQsIEkganVtcGVkIHRvIGFuIGFzc3VtcHRpb247IG1lYSBjdWxwYS4NCg0KDQogICogICBU byB5b3VyIGV4cGxhbmF0aW9uOiBZZXMsIHRoZXJlIGFyZSBDQXMgdGhhdCBwcm92aWRlIE9DU1Ag dGhhdCBkb24ndCBwbGFjZSBpdCBpbiBjZXJ0aWZpY2F0ZXMuIE15IHF1ZXN0aW9uIGhhcyBiZWVu IHRvIGZpZ3VyZSBvdXQgd2hlcmUgYW5kIGhvdyB0aGF0IGluZm9ybWF0aW9uIGlzIHJlYWNoaW5n IFJQcywgc2luY2UgdGhlIHB1cnBvc2Ugb2YgdGhpcyBleHRlbnNpb24gaXMgdG8gc2F5IFJQcyBz aG91bGQgaWdub3JlIHRoYXQgaW5mb3JtYXRpb24uIFRvIHdpdCwgd2UndmUgaWRlbnRpZmllZCBs b2NhbCBwb2xpY3kgYW5kIGNvbmZpZ3VyYXRpb24gYXMgYW4gYW5zd2VyLCB3aGljaCB5b3VyIHBy ZXZpb3VzIHJlcGx5IEkgdGhpbmsgdW5jYXRlZ29yaWNhbGx5IHNob3dzLiBJZiB0aGF0J3Mgbm90 IHRoZSBjYXNlLCBJJ20gaG9waW5nIHlvdSBjYW4gZXhwbGFpbiB3aGVyZSBlbHNlIHRoaXMgaW5m b3JtYXRpb24gY29tZXMgZnJvbSwgc2luY2Ugd2UgYWdyZWUgdGhhdCBpdCdzIG5vdCB0aGUgY2Vy dGlmaWNhdGUuDQoNCk5vLCB0aGlzIGlzIGNvcnJlY3QuDQoNCg0KDQogICogICBJcyB5b3VyIHBv aW50LCB0aGVuLCB0aGF0IHRoaXMgZXh0ZW5zaW9uIHNob3VsZCBiZSBwcmVzZW50LCBidXQgbm90 IGFmZmVjdCBhbnkgcHJvY2Vzc2luZyB3aGF0c29ldmVyIGJ5IHRoZSBSUCwgaW4gdGVybXMgb2Yg UkZDIDUyODAgcHJvY2Vzc2luZz8gSWYgc28sIHdoYXQgaXMgdGhlIHBvaW50IGFuZCB2YWx1ZSB0 byBwdXR0aW5nIHNvbWV0aGluZyBpbiBmb3IgUlBzIHRoYXQgUlBzIGNhbm5vdCBhbmQgZG8gbm90 IHVzZT8NCg0KTXkgcG9pbnQgaXMgdGhhdCwgYXMgd2l0aCBhbGwgNTI4MCBleHRlbnNpb25zLCBh biBSUCBpcyBmcmVlIHRvIHVzZSB0aGUgc2VtYW50aWMgaW5mb3JtYXRpb24gaW4gdGhlIGV4dGVu c2lvbiwgb3Igbm90LiBTcGVha2luZyBmb3IgbXlzZWxmLCBhbmQgbXkgZW1wbG95ZXIsIGlmIHdl IHNhdyBhIGNlcnQgd2l0aCDigJxubyByZXZvY2F0aW9uIGluZm9ybWF0aW9uIGF2YWlsYWJsZeKA nSB3ZeKAmWQgaG9ub3IgaXQuIDopICBUaGF0IG1lYW5zLCB3ZSB3b3VsZCBpZ25vcmUgYW4gcG9z c2libHktc3RhcGxlZCBPQ1NQIFRMUyBkYXRhLiBEb2VzIHRoYXQgYW5zd2VyIHlvdXIgcXVlc3Rp b24/IEZvciBPcGVuU1NMLCBJIHdvdWxkIGV4cGVjdCB0aGF0IGluaXRpYWxseSBzdWNoIGEgYSBj ZXJ0IHdvdWxkIHNldCBhIGZsYWcgdGhhdCBhcHBsaWNhdGlvbnMgY2FuIHF1ZXJ5IGFuZCB0aGVu LCBpbiBhIGxhdGVyIHJlbGVhc2UsIHRoZSBsaWJyYXJ5IGl0c2VsZiB3b3VsZCB1c2UgdGhhdCBm bGFnIHRvIHNraXAgQ1JMLCBPQ1NQIGNoZWNraW5nLCBldGMuICBPbmUgb2YgdGhvc2UgY3Jhenkg a2lkcyBvdmVyIHRoZXJlIGlzIGdvaW5nIGZ1bGwtb24gaW50byBjZXJ0IHZhbGlkYXRpb24gcGF0 aHMuIEJ1dCB0aGF04oCZcyBqdXN0IGEgZ3Vlc3MuDQoNCg0K --_000_45D17BD8263E4B51B77F7B2E02B80B3Dakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <60F9D884BB7A674ABE9E266154DDD83C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjg0NjQwOTM2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA2MjM4NDA2NDt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE3Nzg1MjI2Mzk7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MTAyNjY5MDAgLTE1MjEwNjMxOTQgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxMDg7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9u dC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkknbSBub3Qgc3VyZSB3aHkgeW91J3Jl IHJlZmVyZW5jaW5nIFdlYiBQS0kgLSBJIGNlcnRhaW5seSBoYXZlbid0IC0gYW5kIEknbSBub3Qg c3VyZSB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gaGlnaGxpZ2h0IHRoYXQgaXMgZGlmZmVyZW50IGZy b20gd2hhdCBJIHNhaWQ/PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllvdeKAmXJlIHJpZ2h0LCBJIGp1bXBlZCB0byBhbiBhc3N1bXB0aW9uOyBtZWEgY3VscGEu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm8yIj5UbyB5b3VyIGV4cGxhbmF0aW9uOiBZZXMsIHRoZXJlIGFy ZSBDQXMgdGhhdCBwcm92aWRlIE9DU1AgdGhhdCBkb24ndCBwbGFjZSBpdCBpbiBjZXJ0aWZpY2F0 ZXMuIE15IHF1ZXN0aW9uIGhhcyBiZWVuIHRvIGZpZ3VyZSBvdXQgd2hlcmUgYW5kIGhvdyB0aGF0 IGluZm9ybWF0aW9uIGlzIHJlYWNoaW5nIFJQcywgc2luY2UNCiB0aGUgcHVycG9zZSBvZiB0aGlz IGV4dGVuc2lvbiBpcyB0byBzYXkgUlBzIHNob3VsZCBpZ25vcmUgdGhhdCBpbmZvcm1hdGlvbi4g VG8gd2l0LCB3ZSd2ZSBpZGVudGlmaWVkIGxvY2FsIHBvbGljeSBhbmQgY29uZmlndXJhdGlvbiBh cyBhbiBhbnN3ZXIsIHdoaWNoIHlvdXIgcHJldmlvdXMgcmVwbHkgSSB0aGluayB1bmNhdGVnb3Jp Y2FsbHkgc2hvd3MuIElmIHRoYXQncyBub3QgdGhlIGNhc2UsIEknbSBob3BpbmcgeW91IGNhbiBl eHBsYWluIHdoZXJlDQogZWxzZSB0aGlzIGluZm9ybWF0aW9uIGNvbWVzIGZyb20sIHNpbmNlIHdl IGFncmVlIHRoYXQgaXQncyBub3QgdGhlIGNlcnRpZmljYXRlLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObywgdGhpcyBpcyBjb3JyZWN0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPklzIHlvdXIgcG9pbnQs IHRoZW4sIHRoYXQgdGhpcyBleHRlbnNpb24gc2hvdWxkIGJlIHByZXNlbnQsIGJ1dCBub3QgYWZm ZWN0IGFueSBwcm9jZXNzaW5nIHdoYXRzb2V2ZXIgYnkgdGhlIFJQLCBpbiB0ZXJtcyBvZiBSRkMg NTI4MCBwcm9jZXNzaW5nPyBJZiBzbywgd2hhdCBpcyB0aGUgcG9pbnQgYW5kIHZhbHVlDQogdG8g cHV0dGluZyBzb21ldGhpbmcgaW4gZm9yIFJQcyB0aGF0IFJQcyBjYW5ub3QgYW5kIGRvIG5vdCB1 c2U/Jm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15 IHBvaW50IGlzIHRoYXQsIGFzIHdpdGggYWxsIDUyODAgZXh0ZW5zaW9ucywgYW4gUlAgaXMgZnJl ZSB0byB1c2UgdGhlIHNlbWFudGljIGluZm9ybWF0aW9uIGluIHRoZSBleHRlbnNpb24sIG9yIG5v dC4gU3BlYWtpbmcgZm9yIG15c2VsZiwgYW5kIG15IGVtcGxveWVyLCBpZiB3ZSBzYXcgYSBjZXJ0 IHdpdGgg4oCcbm8gcmV2b2NhdGlvbiBpbmZvcm1hdGlvbiBhdmFpbGFibGXigJ0gd2XigJlkIGhv bm9yIGl0LiA6KSZuYnNwOw0KIFRoYXQgbWVhbnMsIHdlIHdvdWxkIGlnbm9yZSBhbiBwb3NzaWJs eS1zdGFwbGVkIE9DU1AgVExTIGRhdGEuIERvZXMgdGhhdCBhbnN3ZXIgeW91ciBxdWVzdGlvbj8g Rm9yIE9wZW5TU0wsIEkgd291bGQgZXhwZWN0IHRoYXQgaW5pdGlhbGx5IHN1Y2ggYSBhIGNlcnQg d291bGQgc2V0IGEgZmxhZyB0aGF0IGFwcGxpY2F0aW9ucyBjYW4gcXVlcnkgYW5kIHRoZW4sIGlu IGEgbGF0ZXIgcmVsZWFzZSwgdGhlIGxpYnJhcnkgaXRzZWxmIHdvdWxkIHVzZQ0KIHRoYXQgZmxh ZyB0byBza2lwIENSTCwgT0NTUCBjaGVja2luZywgZXRjLiZuYnNwOyBPbmUgb2YgdGhvc2UgY3Jh enkga2lkcyBvdmVyIHRoZXJlIGlzIGdvaW5nIGZ1bGwtb24gaW50byBjZXJ0IHZhbGlkYXRpb24g cGF0aHMuIEJ1dCB0aGF04oCZcyBqdXN0IGEgZ3Vlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_45D17BD8263E4B51B77F7B2E02B80B3Dakamaicom_-- From nobody Sat Nov 14 12:04:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DAF3A1088 for ; Sat, 14 Nov 2020 12:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1U1ys6hNPhe for ; Sat, 14 Nov 2020 12:04:47 -0800 (PST) Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 180533A1085 for ; Sat, 14 Nov 2020 12:04:47 -0800 (PST) Received: by mail-pl1-f177.google.com with SMTP id w11so6153469pll.8 for ; Sat, 14 Nov 2020 12:04:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NjIqT75QSTWltkW4GWcUKcBYqCFtPop6b/eMED788zY=; b=Vyu9hluBOWfOWe0uxSHz+eFvNZNlw5X5UkcClJvehlxXgPsHZuldNs9UnuvnrdplGR 9gtezHJJOW9T0Z40JZX/f0IXwUZR3DetDJfzJ6HMK8tMAfxr0EGfzLqQz3qIBJsCQfP+ QCjEycJ9AWOr4gu0MfBco3Pacpumt3xjoCJYyKX/q3eE4PPtAmvBBGi/uZxnKoaQHQdl 5c0o7BdMdXVw8gKNd4+ecq1M2Yf13V1JeNpY8xKfeWH7wgSYpEmmkB5qFjOkAQ1vocKU W/Mrsyx0pihZpJhr5A9wJwCMfYGojNDZhH1KYt8VSE9nCRUNmTaHhOVhZyRxB5QiLvEK D7hQ== X-Gm-Message-State: AOAM531nhSTY7qWWlte23Hg70m8X3NQsrS0g4KWapYKf+7x24TamxyTz kXf5Riu4TIywZpmbpFXmeIXZiovJ1kA= X-Google-Smtp-Source: ABdhPJyZmDZaVXcRZl4bVeHnJ3uAwx/RPkNDNNiFx3XOe9/RJ/UOIN8U+Z2xSg3fiVftEYH+/qzsHg== X-Received: by 2002:a17:90a:c381:: with SMTP id h1mr9326207pjt.2.1605384286055; Sat, 14 Nov 2020 12:04:46 -0800 (PST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com. [209.85.216.54]) by smtp.gmail.com with ESMTPSA id t85sm11567020pgb.29.2020.11.14.12.04.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Nov 2020 12:04:45 -0800 (PST) Received: by mail-pj1-f54.google.com with SMTP id gv24so1932331pjb.3 for ; Sat, 14 Nov 2020 12:04:45 -0800 (PST) X-Received: by 2002:a17:902:8a8b:b029:d7:eba5:7845 with SMTP id p11-20020a1709028a8bb02900d7eba57845mr6949945plo.78.1605384285087; Sat, 14 Nov 2020 12:04:45 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> <45D17BD8-263E-4B51-B77F-7B2E02B80B3D@akamai.com> In-Reply-To: <45D17BD8-263E-4B51-B77F-7B2E02B80B3D@akamai.com> From: Ryan Sleevi Date: Sat, 14 Nov 2020 15:04:34 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Russ Housley , LAMPS , Erik Andersen Content-Type: multipart/alternative; boundary="0000000000000a6ed805b416a830" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 20:04:49 -0000 --0000000000000a6ed805b416a830 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Nov 14, 2020 at 10:57 AM Salz, Rich wrote: > My point is that, as with all 5280 extensions, an RP is free to use the > semantic information in the extension, or not. > Sure, and there is a wide open space for private extensions, if they have no discernable effect on processing. You could accomplish the same thing by a certificate profile that said "OU =3D No Revocation Provided". Or by stating it in a CP/CPS. The point of putting something into an extension, particularly looking for a standard one, is for when you want the RP to use that semantic information, which means defining what those semantics are. And if you actually think about what the semantics would be for this, my point is that you can already accomplish that with existing capabilities, so there's no point to standardizing in the first place a feature that would be net-security-negative compared to those existing capabilities. > Speaking for myself, and my employer, if we saw a cert with =E2=80=9Cno r= evocation > information available=E2=80=9D we=E2=80=99d honor it. :) That means, we = would ignore an > possibly-stapled OCSP TLS data. Does that answer your question? > It opens more. I think that if you carry this through to its logical consequence, you would also see this doesn't make sense. For example, in the scenario you described where customers configure explicit OCSP URLs that they obtain through some out-of-bands (non-certificate) means, you could simply tell them "Don't do that". It's a local policy thing that's saying "Do more work", and it's much easier to just simply not set a local policy that says "do unnecessary work". This extension would be effectively "stop hitting yourself", and that's silly. Now, for the situation of stapled response, for a certificate that says "I don't have revocation data", that's also silly. Either one of three things is true here: 1) The CA actually provides revocation data, the stapled response is for the cert, ergo the CA is a liar 2) The CA doesn't actually provide revocation data, the stapled response is for some other cert, in which case, that should be a protocol error, because it's stupid to let stupid servers send stupid things 3) The CA doesn't actually provide revocation data, the stapled response isn't even an OCSP response in the first place, and that too should ... be a protocol error. This is why I argue it doesn't save work if you attach semantics to it, and it doesn't make sense if you don't attach semantics. > For OpenSSL, I would expect that initially such a a cert would set a flag > that applications can query and then, in a later release, the library > itself would use that flag to skip CRL, OCSP checking, etc. One of those > crazy kids over there is going full-on into cert validation paths. But > that=E2=80=99s just a guess. > But, again, I don't think this makes any sense. What you're describing here is the library has configured CRLs and OCSP servers, *outside* of the certificate, and that such configuration doesn't make sense for the certificate. The presumption here is that the library/author is sufficiently knowledgeable to configure such sources, in which case, the application author can totally simply configure themselves to not check such responses for a particular CA, and that said particular CA only issue these certificates. To really argue for the extension to have value, you have to go even more meta, by implicitly suggest that a single CA should be able to issue both types of such certificates. Yet there's no actually compelling reason to need that, given said CA can just use two separate issuing intermediates, and things are fine. The only benefit to standardization is if we expect this to be such a common case, that it would benefit from a standard and interoperable implementations, such that developers don't have to configure local policy. However, I think that's also nonsense, since to even get such a CA in the first place, you.... depend on local policy. This is what I mean by carrying through the use case through its logical consequences. I totally acknowledge that there are a lot of assumptions that are made in that previous paragraph, and you might be considering some different case. But for all the unlisted permutations here of explanations or constraints, it still seems that it'd be useless. So if there's a case that's missing, some detail that actually makes it make sense and not just yet another way to accomplish the same thing in PKI that we have a dozen other ways of doing, that's what I'd be keen to learn. > --0000000000000a6ed805b416a830 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 14, 2020 at 10:57 AM Salz= , Rich <rsalz@akamai.com> wro= te:

My point is that, as with all 5280 extensions, an RP= is free to use the semantic information in the extension, or not.


Sure, and there = is a wide open space for private extensions, if they have no discernable ef= fect on processing. You could accomplish the same thing by a certificate pr= ofile that said "OU =3D No Revocation Provided". Or by stating it= in a CP/CPS.

The point of putting something into = an extension, particularly looking for a standard one, is for when you want= the RP to use that semantic information, which means defining what those s= emantics are. And if you actually think about what the semantics would be f= or this, my point is that you can already accomplish that with existing cap= abilities, so there's no point to standardizing in the first place a fe= ature that would be net-security-negative compared to those existing capabi= lities.
=C2=A0

Speaking for myself, and my employer, if we saw a cert with =E2=80=9Cno= revocation information available=E2=80=9D we=E2=80=99d honor it. :)=C2=A0 That means, we would ignore an possibly-stapled OCSP TLS data. Does that a= nswer your question?

It opens more. I think that if you carry this through to its lo= gical consequence, you would also see this doesn't make sense.

For example, in the scenario you described where customers= configure explicit OCSP URLs that they obtain through some out-of-bands (n= on-certificate) means, you could simply tell them "Don't do that&q= uot;. It's a local policy thing that's saying "Do more work&qu= ot;, and it's much easier to just simply not set a local policy that sa= ys "do unnecessary work". This extension would be effectively &qu= ot;stop hitting yourself", and that's silly.

<= div>Now, for the situation of stapled response, for a certificate that says= "I don't have revocation data", that's also silly. Eithe= r one of three things is true here:
1) The CA actually provides r= evocation data, the stapled response is for the cert, ergo the CA is a liar=
2) The CA doesn't actually provide revocation data, the stap= led response is for some other cert, in which case, that should be a protoc= ol error, because it's stupid to let stupid servers send stupid things<= /div>
3) The CA doesn't actually provide revocation data, the stapl= ed response isn't even an OCSP response in the first place, and that to= o should ... be a protocol error.

This is why I ar= gue it doesn't save work if you attach semantics to it, and it doesn= 9;t make sense if you don't attach semantics.
=C2=A0

For OpenSSL, I would expect = that initially such a a cert would set a flag that applications can query a= nd then, in a later release, the library itself would use that flag to skip CRL, OCSP checking, etc.=C2=A0 One of those crazy kids o= ver there is going full-on into cert validation paths. But that=E2=80=99s j= ust a guess.


<= div>But, again, I don't think this makes any sense. What you're des= cribing here is the library has configured CRLs and OCSP servers, *outside*= of the certificate, and that such configuration doesn't make sense for= the certificate. The presumption here is that the library/author is suffic= iently knowledgeable to configure such sources, in which case, the applicat= ion author can totally simply configure themselves to not check such respon= ses for a particular CA, and that said particular CA only issue these certi= ficates.

To really argue for the extension to have= value, you have to go even more meta, by implicitly suggest that a single = CA should be able to issue both types of such certificates. Yet there's= no actually compelling reason to need that, given said CA can just use two= separate issuing intermediates, and things are fine. The only benefit to s= tandardization is if we expect this to be such a common case, that it would= benefit from a standard and interoperable implementations, such that devel= opers don't have to configure local policy. However, I think that's= also nonsense, since to even get such a CA in the first place, you.... dep= end on local policy.

This is what I mean by carryi= ng through the use case through its logical consequences. I totally acknowl= edge that there are a lot of assumptions that are made in that previous par= agraph, and you might be considering some different case. But for all the u= nlisted permutations here of explanations or constraints, it still seems th= at it'd be useless. So if there's a case that's missing, some d= etail that actually makes it make sense and not just yet another way to acc= omplish the same thing in PKI that we have a dozen other ways of doing, tha= t's what I'd be keen to learn.

--0000000000000a6ed805b416a830-- From nobody Sun Nov 15 03:33:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573103A10B7 for ; Sun, 15 Nov 2020 03:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 6XggGDOkJ2bB for ; Sun, 15 Nov 2020 03:33:50 -0800 (PST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::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 9D72C3A10B3 for ; Sun, 15 Nov 2020 03:33:50 -0800 (PST) Received: by mail-oi1-x231.google.com with SMTP id m143so15683205oig.7 for ; Sun, 15 Nov 2020 03:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I0eO73zZevQlfZIucn94oBL5bm4CahkPXtpycR6fNrU=; b=mMTKls/u3kseJuSq/Y4/11Lab14LFbOYJ+O3bOZlrV0dVmF2mvXww7LOGCDfIHVShL UVtWqTW0J/qzoh8Gy+BdpCq8P4y5Ug/+9/dYJBZUSEaHbVIwBdLcnH2nR5NOjgyB9BVz B009l2jFRam+6BJUxdnp6KHdDIzOXTQUCz+Wg0enmI2hkDN/QY6V5XHUEeCm0tCD0s1q m/ERouuYM7lTpvlKCQEYOVGbpR8F4wi7RZRXPR7TyLDZFkhKQFVHLEkOZ6UeKCcXfRvc xTR7+K19uXgcTF/gjhL2uTUQN8YRZBBrZ7TI/2wqGGwa5FnK8Ky+abU3Ed5yAD83ylNc 7qKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I0eO73zZevQlfZIucn94oBL5bm4CahkPXtpycR6fNrU=; b=ppN1+UtxcIk0zAuX+A7GuQlRlG38oVr+gA30rOIXJOHn2Wt8Nrct5DnKFXWvJBobe7 L+rD1d3GNTJ2nIS16zHs6ikoIZndmhqpHUPkND7cdQbcVybX2epytPXIpQM2eHYEE67Q 79jPH7KnSD9QnyfhGXU0l/ZeGAg6NsDx3y4U/+I6jvbcdwAzNHmLf8acBIGgV74KNgCr K1Btw91J6tMJna2DqGh3hxrj7RKXWNpzdkSlmxT/B0CNlFEEL6u3duGkEMmYJzHuc0+L e2WHuJmpzNI9mh1gds4zxy0m5i5Fjcu6AmkbSeKQDZVBcq34t2D+IeY0RDwRqCPU3nEZ zG/w== X-Gm-Message-State: AOAM530O+U7pcC3YtYggRI2AEcOVCNTr7WJ+XI8QjOnJegZPqmjq1QMZ pK9RcybnwMSlJ5BnvnWGHNkkiVdAtLuxQYb7tPMRmC9kmMPd X-Google-Smtp-Source: ABdhPJyCKpEfJ115/tBnp8shcwGssWMP4NCR4REFUeRmTqyJRzAA3UafeKeD+8r68YmWVdTNKlq4QqPjg9gh0dmdBKM= X-Received: by 2002:aca:72c4:: with SMTP id p187mr6607710oic.165.1605440029519; Sun, 15 Nov 2020 03:33:49 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: <87o8kbj1oi.fsf@fifthhorseman.net> From: Deb Cooley Date: Sun, 15 Nov 2020 06:33:37 -0500 Message-ID: To: LAMPS WG Cc: Michael Richardson , "Cooley, Dorothy E" Content-Type: multipart/alternative; boundary="000000000000aaf44905b423a279" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 11:33:52 -0000 --000000000000aaf44905b423a279 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies for top posting.... -------snip-------------------------------------------------- > I have no idea how ECDSA works with S/MIME encryption. Does anyone have a suggestion here? Is anyone on this list using either ECDSA or EDDSA with e-mail? -----snip--------------------------------------------- I don't have one (and I may never if I retire before US DOD moves off of RSA2048) but an ECDSA cert would be used for digital signature in S/MIME. Encryption would use a separate key/cert - not ECDSA, most likely ECDH with a semi-static scheme (sender is ephemeral, recipient is static). Deb Cooley On Thu, Nov 5, 2020 at 9:57 AM Daniel Kahn Gillmor wrote: > On Wed 2020-11-04 15:18:31 -0500, Michael Richardson wrote: > > I agree that some stability is useful. > > Some certificates that expire past "xx50" would be good, since there wa= s > that > > Y2K hack, which I hope is now gone :-) > > you're talking about GeneralizedTime vs. UTCTime, i think? these > certificates all are after 2050, so they do tickle that particular > boundary. From the "alice" cert (in the ugly dumpasn1 rendering): > > [=E2=80=A6] > 97 32: SEQUENCE { > 99 13: UTCTime 20/11/2019 06:54:18 GMT > 114 15: GeneralizedTime 27/09/2052 06:54:18 GMT > : } > [=E2=80=A6] > > > you have to put in the stuff. I've mentioned this need to > > Carsten at some time. > > If there's an open bug report, i'd be happy to see it so i can weigh in! > > > I don't care what you pretty printer you use, but I think that the huma= n > > readable part has some value. > [=E2=80=A6] > > In ten years, the renderer might print something different, and it migh= t > > actually be valuable to know that something changed. > > The most valuable human-readable part is the stuff in English that > introduces each certificate =E2=98=BA. And it's definitely valuable to k= now > that a particular tool's rendering has changed, but i don't think that > an RFC is the right place to record a changelog of renderer output for > any particular tool. > > > I have no idea how ECDSA works with S/MIME encryption. > > Does anyone have a suggestion here? Is anyone on this list using either > ECDSA or EDDSA with e-mail? > > > I think you are saying that the key generation is intentionally > deterministic > > from a known seed? > > hah, i wish! my code (and my knowledge of the toolchains i'm using) is > not that clever. I just ran the tools in the standard way, and took a > snapshot of their output. Generating from a seed is a good idea for > future work. > > =E2=80=A6does some reading=E2=80=A6 > > Looks like certtool has --provable and --seed options that can be used > for this, at least for RSA and DSA key generation using FIPS PUB186-4 > algorithms (i.e., Shawe-Taylor). I supposed for ECDSA or EDDSA key > generation, we could just deterministically select (hard-code) the secret > key based on a (correctly-sized) digest of a simple string. > > Thanks for the useful feedback and suggestions! > > --dkg > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000aaf44905b423a279 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies for top posting....
-------snip--= ------------------------------------------------
> I have no idea how ECDSA works with S/MIME encr= yption.

Does anyone have a suggestion here?=C2=A0 Is anyone on this list using eith= er
ECDSA or EDDSA with e-mail?
-----snip-----------------------= ----------------------

I don't hav= e one (and I may never if I retire before US DOD moves off of RSA2048) but = an ECDSA cert would be used for digital signature in S/MIME.=C2=A0 Encrypti= on would use a separate key/cert - not ECDSA, most likely ECDH with a semi-= static scheme (sender is ephemeral, recipient is static).

Deb Cooley

On Thu, Nov 5, 2020 at 9:57 AM Daniel Kahn Gillmor &l= t;dkg@fifthhorseman.net> wr= ote:
On Wed 2020= -11-04 15:18:31 -0500, Michael Richardson wrote:
> I agree that some stability is useful.
> Some certificates that expire past "xx50" would be good, sin= ce there was that
> Y2K hack, which I hope is now gone :-)

you're talking about GeneralizedTime vs. UTCTime, i think?=C2=A0 these<= br> certificates all are after 2050, so they do tickle that particular
boundary.=C2=A0 From the "alice" cert (in the ugly dumpasn1 rende= ring):

[=E2=80=A6]
=C2=A097=C2=A0 32:=C2=A0 =C2=A0 =C2=A0SEQUENCE {
=C2=A099=C2=A0 13:=C2=A0 =C2=A0 =C2=A0 =C2=A0UTCTime 20/11/2019 06:54:18 GM= T
114=C2=A0 15:=C2=A0 =C2=A0 =C2=A0 =C2=A0GeneralizedTime 27/09/2052 06:54:18= GMT
=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A0 =C2=A0}
[=E2=80=A6]

> you have to put in the <sourcecode> stuff.=C2=A0 I've mentio= ned this need to
> Carsten at some time.

If there's an open bug report, i'd be happy to see it so i can weig= h in!

> I don't care what you pretty printer you use, but I think that the= human
> readable part has some value.
[=E2=80=A6]
> In ten years, the renderer might print something different, and it mig= ht
> actually be valuable to know that something changed.

The most valuable human-readable part is the stuff in English that
introduces each certificate =E2=98=BA.=C2=A0 And it's definitely valuab= le to know
that a particular tool's rendering has changed, but i don't think t= hat
an RFC is the right place to record a changelog of renderer output for
any particular tool.

> I have no idea how ECDSA works with S/MIME encryption.

Does anyone have a suggestion here?=C2=A0 Is anyone on this list using eith= er
ECDSA or EDDSA with e-mail?

> I think you are saying that the key generation is intentionally determ= inistic
> from a known seed?

hah, i wish!=C2=A0 my code (and my knowledge of the toolchains i'm usin= g) is
not that clever.=C2=A0 I just ran the tools in the standard way, and took a=
snapshot of their output.=C2=A0 Generating from a seed is a good idea for future work.

=E2=80=A6does some reading=E2=80=A6

Looks like certtool has --provable and --seed options that can be used
for this, at least for RSA and DSA key generation using FIPS PUB186-4
algorithms (i.e., Shawe-Taylor).=C2=A0 I supposed for ECDSA or EDDSA key generation, we could just deterministically select (hard-code) the secret key based on a (correctly-sized) digest of a simple string.

Thanks for the useful feedback and suggestions!

=C2=A0 =C2=A0 =C2=A0 =C2=A0--dkg
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000aaf44905b423a279-- From nobody Sun Nov 15 09:50:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF05D3A010A for ; Sun, 15 Nov 2020 09:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=henningkrause.eu header.b=Cg0VCAsK; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=dVBMlZ7C; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=n7gyAxjI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywpcJrIR4x-c for ; Sun, 15 Nov 2020 09:50:43 -0800 (PST) Received: from de-s01-gw1.mail.cloud.nospamproxy.com (de-s01-gw1.mail.cloud.nospamproxy.com [193.37.132.131]) (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 DF8AB3A00F7 for ; Sun, 15 Nov 2020 09:50:42 -0800 (PST) DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1e; t=1605462638; bh=KWFF+Hg01EINozg2c2CQXov4nh4YNQTHPzA+5E6qigI=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=ed25519-sha256; b= Cg0VCAsK16Ski3XGNlRe+wjZkyF3I+iGewJtIIuMJdHTSkZeuXzK6wSV7+w2HQRqQaA6zvRkejV8ec0BIGPZDg== DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1r; t=1605462638; bh=KWFF+Hg01EINozg2c2CQXov4nh4YNQTHPzA+5E6qigI=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=rsa-sha256; b= dVBMlZ7C4F/sGONDJX7qnzn0XqOKsrJRM0xW4b8rQh918ll6+Ob5BDLds/7T0aUH3PDDkedB6EM0NM7mi6cc7GZENRNBvfq/gMT5XO+C5ZEfZhN3aamwgfhQIa+qToKzM0zMyleKExmgJwxuVEBUw4DD5YRn9t3+G6sWA1zWyO0= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k2KWbGa7CEcvXQnS3c83yBoqa+HWktOytqvX7GVBwqOuO0TWUQ/jGek818ZmhvFOHnVDdYPaA8NlA+EDKy3nzvtm/ibWlC4UMFgL5uFWuWG20TVN9xJ0EauuHDIUq3IQZg+CJ9u38MxsdePWnw49yOyl3oaLDeGHt6cpY9fdR9AGyR0tNL4etElqKzZQtBAoZkrlHy6ND/EutQvm40mAx296uSLG866dGcPJFXAVPuWx59xehhj4+mkxI6G09LoEeM0HvMAGx+kCK62+bcFHjiSwgsMfeyzyVSg5UHXWqEYovb8/5rozsd1wr/eQXpWJEO9jPOLdOXXU/gwfTmMPIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWFF+Hg01EINozg2c2CQXov4nh4YNQTHPzA+5E6qigI=; b=E/bqX/NhHUTNZczeItjpYcDUvvdjPoY9tSXh9IJ9EnkNBksRAU+HTU18+Y7i5W01eMMwgjGJc/Lm0oFP8WMJe416ZdYjluQag2rvPRuTCQMCHwg3rAGUwXPQTuH63AWndzcu9MvgoiB98BmnsufOpS7U4eHXt02FqpaAAmuu9lEfeHTburEKVhtYS7E3bgzGDvfmMabnfSbqhua1/IgGhbPOQDKj8+3J59fOiWPr8JkJXnVlY3EaoW+r/SQSAYBWWTD2tZH6cxSYrFmZlJS0JNb6bZT7neRKKNrmMzDbTN4JIuZwj+bUgoMExXn1sToSjm469O2uDNOm/6hxC19beg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=henningkrause.eu; dmarc=pass action=none header.from=henningkrause.eu; dkim=pass header.d=henningkrause.eu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=henningkrause.eu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KWFF+Hg01EINozg2c2CQXov4nh4YNQTHPzA+5E6qigI=; b=n7gyAxjIwiNC71kBGM6IHn4MPkKgN8e0hm8/uYIEglMjKjuRLRu4liBU1MYQ5ZhFdRHQYwwsxGuUHiQJY8xjxF91KbO89MxB96Cd17HOr+w/WLGxMCXb5mTq1+EGrmSoGw7ftz4xlXlix/CaesdjKzC8OKEbV5GHIyvYnVpjdW8= From: Henning Krause To: Deb Cooley , LAMPS WG CC: "Cooley, Dorothy E" , Michael Richardson Thread-Topic: [lamps] WG adoption of draft-dkg-lamps-samples ? Thread-Index: AQHWsrQREl/KbJsyWUuVKyLgcBjGB6m4Km0AgAAi/QCAAByBgIABN1CAgA9/rYCAAGeH0A== Date: Sun, 15 Nov 2020 17:50:34 +0000 Message-ID: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-Mentions: debcooley1@gmail.com X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=henningkrause.eu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c226df3d-1e83-43dd-44b8-08d8898ef48a x-ms-traffictypediagnostic: DBBPR08MB4233: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3K9u9zGQcsjlyl+sn2nMXMDUR3PKDd0d+Yc8bDX3zlYf38q+recJYWkl3cHFj6tCTx5Hs0mK1QFj0UFg3eMzerYSudSSqndJS2Q+Wfj+qA3GwWD2I1hCmFGBRQJ0TdZbYzHg6FT+FjfiYyC609qtpado4d6NcbIjzfFxdM/WM7nD/9YLTDMcuUeAhzB6mG002tGBq6lNVbNdSXu/hXZSnYgKHpZmX2r44BM/6utaeO9c1uZ70C56EQCCgH/SI7PlZjujCftXL5JR2MUHSAwRIFhTIV+ihxrT6cyaUBZ47wXgXiRlBc0mB3QB8UMO08SDdwrLtdHJfytZ32u2elmh4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3498.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(366004)(376002)(346002)(136003)(396003)(6506007)(55016002)(9686003)(7696005)(316002)(8676002)(110136005)(54906003)(186003)(86362001)(8936002)(4326008)(2906002)(478600001)(71200400001)(5660300002)(66446008)(66946007)(76116006)(66476007)(33656002)(52536014)(83380400001)(64756008)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RUFIUS9VSFBtQlhJd1JHREFrVnJRbTVEZHEvMmFFajJJakdnbjFmazcvMjVy?= =?utf-8?B?ZU5KbFdJWjZSZTRQV296MFV1L0srejB0c25xUFFJV2lEamthQStwVFFCWkk5?= =?utf-8?B?QXZFdlFWbmhsbDhUdHZJMHJJUHlWNnJkMVBIT2ZSZUw2SU5YTFhYUGVKU3hj?= =?utf-8?B?Y0NCcnNTUTlHbk0xUUVmb3o0eCtlbWpFYjFmZWpDYVJJSnMraUs1TG5OU1ZT?= =?utf-8?B?WGRBWXNYMlNhRzVWbHdISkdsT0xuMTdEYXVMNXBFU09qZFQwQVFuSDBxRy8x?= =?utf-8?B?Z1J3NDl5clVST0N6ZitMOUh0aXo4RUdIZTFBaFFFWk5xZURDOTNUQTlVcVlH?= =?utf-8?B?M0xmd1dta1k4SmVPOEU4K2JhWlhKaldzQUlGVUtPU2ZzM3g1Y1pmM0NvbUw5?= =?utf-8?B?SHgyRC81REpmNnlMeERKNWlMQWRpQ1ozc0taOHhJU1VIdTNvVE9QczM4SkJ1?= =?utf-8?B?QjJwcnczaEEwRk9TQ2RjOTd3V0todEFCL1Byc0drR2NhWVM3dU9pdFlxRi9C?= =?utf-8?B?L0tXQzloSDNYS242L3NlblBoSEhEem04ZHZsVkI5R0V0VXVXb1Fzd1FxUWpz?= =?utf-8?B?aVFnS2ZjNVlxRDU5d0I2aGwrT2g2YkFVT0VUWldkSWtEeUNFMUNnSzYzWXdX?= =?utf-8?B?Mm1ka1g1bENyRmZMTFJMVVNZYWQ5QTQybytESWgzQ0JkcE1wTHpucTgwY0xK?= =?utf-8?B?Ui9EQ3dYVksvMFdFUkp1YzhaYjJTWGpSbktUbVQxRWR4Y0sxSE1aaGlRVzda?= =?utf-8?B?VjdqQlhLMFR4N1dET2RrVXc5bHJpbzRhY1VIR0pVeWE1bXlWR2NzNjBGcjJp?= =?utf-8?B?Qkl4SlFHNDROSytDTmo5YUJvNkZ2MWV1b2dIY2h1UDhJeWI4OFErcERhNHlM?= =?utf-8?B?WVRPOXZoUWhpc2U3OUc0STlFczZGL1Ftb3NpbXF6dG1vQlUxSkFyOVdLN3Yw?= =?utf-8?B?UlQzN3V3UU5BZGVSNVljU2FURVJ5NSs4OFkvZ0lDT2dpcjV3TG5wNVJtelJN?= =?utf-8?B?aVRCUHBleWpUUWtUV3FwYlFVNklLWGZjeXR0OFgxNERVUDdqcERkeWVSTzVK?= =?utf-8?B?VDZDMUxodi9ocFduaXM0S2piejQvbmxUWS9ZSzRuN3B2aGxRTFB4OHFjRlgy?= =?utf-8?B?cXh3Wml0T3dmdnlEQm5kTHA2SFUzZnlpSlZrZjU1RWJjUzRjSlpJU2Y2ZVVQ?= =?utf-8?B?UTMrdFIyYWVGaGVJUjd5MjM4Q1B3dWljUDNnQXJhbGMxbTZoN1RJbjRycnBK?= =?utf-8?B?b2R5QUpLTU83M2dNZXBrQ2tFajgveWlKdjVDM1pLNUM5NWE1Zz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: henningkrause.eu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR08MB3498.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c226df3d-1e83-43dd-44b8-08d8898ef48a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2020 17:50:35.0181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2041dc2d-8eaa-4f51-96a8-b4923f969cba X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R4ldFLnYwfAf8hxy+Kh95vG4d0U3SmStDzPpXerkR6B+Sh9sassqZeQDY2psciayRfkUeGaEUSouJcp57dOsVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4233 Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 17:50:45 -0000 PiAtLS0tLS0tc25pcC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IA0KPiA+IEkgaGF2ZSBubyBpZGVhIGhvdyBFQ0RTQSB3b3JrcyB3aXRoIFMvTUlN RSBlbmNyeXB0aW9uLg0KPiANCj4gRG9lcyBhbnlvbmUgaGF2ZSBhIHN1Z2dlc3Rpb24gaGVyZT8g IElzIGFueW9uZSBvbiB0aGlzIGxpc3QgdXNpbmcgZWl0aGVyDQo+IEVDRFNBIG9yIEVERFNBIHdp dGggZS1tYWlsPw0KPiANCj4gLS0tLS1zbmlwLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJIGRvbid0IGhhdmUgb25lIChhbmQgSSBtYXkgbmV2ZXIg aWYgSSByZXRpcmUgYmVmb3JlIFVTIERPRCBtb3ZlcyBvZmYgb2YNCj4gUlNBMjA0OCkgYnV0IGFu IEVDRFNBIGNlcnQgd291bGQgYmUgdXNlZCBmb3IgZGlnaXRhbCBzaWduYXR1cmUgaW4gUy9NSU1F Lg0KPiBFbmNyeXB0aW9uIHdvdWxkIHVzZSBhIHNlcGFyYXRlIGtleS9jZXJ0IC0gbm90IEVDRFNB LCBtb3N0IGxpa2VseSBFQ0RIIHdpdGgNCj4gYSBzZW1pLXN0YXRpYyBzY2hlbWUgKHNlbmRlciBp cyBlcGhlbWVyYWwsIHJlY2lwaWVudCBpcyBzdGF0aWMpLg0KPiANCg0KSSd2ZSBjcmVhdGVkIGFu IEVDRFNBIGNlcnRpZmljYXRlIHVzaW5nIE9wZW5TU0wgYW5kIHVzZWQgdGhhdCBzdWNjZXNzZnVs bHkgdG8gZW5jcnlwdCBhbiBTTUlNRSBtZXNzYWdlLiBPcGVuU1NMIHNpbXBseSB1c2VzIHRoZSBF Q0RTQSBrZXkgZm9yIEVDREguIEkndmUgYWxzbyBjcmVhdGVkIGEgcHJvdG90eXBlIGluIEMjIHRv IHRoZSBzYW1lIHRoaW5nIGFuZCB3YXMgYWJsZSB0byBkZWNyeXB0IHRoZSBtZXNzYWdlIGNyZWF0 ZWQgYnkgT3BlblNTTC4NCg0KU28gY3JlYXRpbmcgc2FtcGxlIGNlcnRpZmljYXRlcyBpcyByZWxh dGl2ZWx5IHN0cmFpZ2h0IGZvcndhcmQ6DQoNCkdlbmVyYXRlIGtleToNCmVjcGFyYW0gLW91dCBl Y2RzYS5rZXkgLW5hbWUgc2VjcDI1NnIxIC1nZW5rZXkNCg0KVGhlIGtleSBjYW4gdGhlbiBiZSB1 c2VkIHRvIGNyZWF0ZSBhIGNlcnRpZmljYXRlIHNpZ25pbmcgcmVxdWVzdCBhbmQgdGhlIGFjdHVh bCBjZXJ0Lg0KDQpUaGUgZW5jcnlwdGlvbiBpbmRlZWQgdXNlcyBhbiBlcGhlbWVyYWwga2V5IGZv ciB0aGUgc2VuZGVyIGFuZCB0aGUgc3RhdGljIHB1YmxpYyBrZXkgZnJvbSB0aGUgcmVjaXBpZW50 cyBjZXJ0aWZpY2F0ZS4NCg0KQERlYiBDb29sZXksIHdoeSBkbyB5b3Ugc2F5IHlvdSB3b3VsZCBh IGRpZmZlcmVudCBjZXJ0aWZpY2F0ZT8gDQoNCktpbmQgcmVnYXJkcywNCkhlbm5pbmcgDQo= From nobody Sun Nov 15 11:18:36 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FDE3A0140 for ; Sun, 15 Nov 2020 11:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usRVq2mpB_pE for ; Sun, 15 Nov 2020 11:18:32 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8550B3A0138 for ; Sun, 15 Nov 2020 11:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605467911; d=isode.com; s=june2016; i=@isode.com; bh=wJ7XqjJxIuT2/2VFQiTivB6OnBdj7XHBCDb1FYTSMIo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=hBrY8/UUS0plsdny0m+ilxNxFtO/mm+8gvZM72RSRjnPzwITvHUBoyqsi6VVFTyFI1nTt6 98WT5Zhl8369aeB9n1cI0CCRc2Cmid7t3qAzDZ5rSjC3OOnY/Lyy9eRhHNojS6VcPRoNXb BP6oA5IPDGL2ksyZM9GOPts6KNbcZpM=; Received: from [10.218.152.53] ((unknown) [185.69.144.45]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 15 Nov 2020 19:18:31 +0000 X-SMTP-Protocol-Errors: NORDNS From: Alexey Melnikov In-Reply-To: <15048.1604516623@localhost> Date: Sun, 15 Nov 2020 19:18:29 +0000 Cc: Daniel Kahn Gillmor , LAMPS WG Message-Id: References: <15048.1604516623@localhost> To: Michael Richardson X-Mailer: iPhone Mail (17G80) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:18:34 -0000 > On 4 Nov 2020, at 19:03, Michael Richardson wrote:= >=20 > Alexey Melnikov wrote: >>> I'm happy to cede authority on the document to the WG consensus. I >>> volunteer to continue as editor of the document in this case, but i'd >>> also be happy if someone else wanted to edit it. >=20 >> I agree this document should be adopted by the WG. >=20 >> I am not yet sure that the document ever need to become an RFC (as >> opposed to just staying as a draft that gets refreshed periodically), >> but I can probably be convinced. >=20 > I guess any references to it from other documents would be informational, s= o > there would be no downref issue? Yes. From nobody Sun Nov 15 21:58:00 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE023A1460 for ; Sun, 15 Nov 2020 21:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm5b3YJAJ5AE for ; Sun, 15 Nov 2020 21:57:55 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862DD3A140B for ; Sun, 15 Nov 2020 21:57:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E5591300B8B for ; Mon, 16 Nov 2020 00:57:47 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6ONZuuxDu-jH for ; Mon, 16 Nov 2020 00:57:46 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id CA476300A87 for ; Mon, 16 Nov 2020 00:57:46 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: Date: Mon, 16 Nov 2020 00:57:47 -0500 To: LAMPS X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] Need volunteers for LAMPS at IETF 109 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 05:57:59 -0000 Please volunteer for jabber scribe or minutes in the etherpad. I would = like to get this sorted by email to avoid using meeting time. Russ From nobody Mon Nov 16 00:14:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2443A155D for ; Mon, 16 Nov 2020 00:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae3ECpf8J4eh for ; Mon, 16 Nov 2020 00:14:35 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF993A1504 for ; Mon, 16 Nov 2020 00:14:34 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AG8EMMO000485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Nov 2020 03:14:27 -0500 Date: Mon, 16 Nov 2020 00:14:22 -0800 From: Benjamin Kaduk To: Henning Krause Cc: Deb Cooley , LAMPS WG , "Cooley, Dorothy E" , Michael Richardson Message-ID: <20201116081422.GR39170@kduck.mit.edu> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:14:36 -0000 On Sun, Nov 15, 2020 at 05:50:34PM +0000, Henning Krause wrote: > > -------snip-------------------------------------------------- > > > > > I have no idea how ECDSA works with S/MIME encryption. > > > > Does anyone have a suggestion here? Is anyone on this list using either > > ECDSA or EDDSA with e-mail? > > > > -----snip--------------------------------------------- > > > > I don't have one (and I may never if I retire before US DOD moves off of > > RSA2048) but an ECDSA cert would be used for digital signature in S/MIME. > > Encryption would use a separate key/cert - not ECDSA, most likely ECDH with > > a semi-static scheme (sender is ephemeral, recipient is static). > > > > I've created an ECDSA certificate using OpenSSL and used that successfully to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for ECDH. I've also created a prototype in C# to the same thing and was able to decrypt the message created by OpenSSL. I think OpenSSL is not supposed to do that, and furthermore I thought there was a bug report on github about OpenSSL doing so, but I couldn't find it quickly if it exists. -Ben From nobody Mon Nov 16 00:29:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCDD3A15E5 for ; Mon, 16 Nov 2020 00:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=henningkrause.eu header.b=ufZQxi3n; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=74Eq8mWT; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=Va0Qce/p Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsGJikmrBUv2 for ; Mon, 16 Nov 2020 00:29:27 -0800 (PST) Received: from de-s01-gw1.mail.cloud.nospamproxy.com (de-s01-gw1.mail.cloud.nospamproxy.com [193.37.132.131]) (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 078513A15FE for ; Mon, 16 Nov 2020 00:29:25 -0800 (PST) DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1e; t=1605515362; bh=UdbfvGZMTn3LhljEi6h/2lMXH3NNBmusnIyD0ET78kI=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=ed25519-sha256; b= ufZQxi3nG/R9y6ImFSl9UlMHui9t9F3KaocQxVelRHcd6xnwBhk2Z/oaXbTHI+/RZsf7sunAMg045OUVjx4SDg== DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1r; t=1605515362; bh=UdbfvGZMTn3LhljEi6h/2lMXH3NNBmusnIyD0ET78kI=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=rsa-sha256; b= 74Eq8mWTf3Z7H3BCNeqL8cgxp15DXzyMcMxXYF+07ri1/dxyR9ow/SRvr4nqfvTOFjGUbCRlOPrMSXu3lVCmecNEn+B+wVa/37YtlvDKJwSVVD5TLpKiVDtc8OlM8bxVw5Pt4HJSzO1mjU7gkNzmBp/bKMvIAgQkGqk8kzdeAm8= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XOMfClia4rHas47v2L7ab2anLuH6VJ7d6jzhIgh9/Hha3fdQ/do4ekAylIwFg7p3SxtjNelpozaU1g/b5XDHbXOpy1/W1IllrlEevzGQvA/cWGAn28RzRy+acQBsHupzex8GaOZ972oB4MZFOFk+UxTi2KnJdralBW7ZhUO06ZSbKvGH/yeeLUvg0nI95i7WCTLhKwwti0XpgMOFjizW3mwUBU1V5kxMiXjHJh8IWxR3PvLw2Awe+y1lflqfexSq0dFIb/wg20GQ7pJT6dgatTkw5LKX6NRoB3UfE4rvEbZTH+IbG20p1kN/p9UOAWd9wtBrfz0jEtitRIavKM1C9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UdbfvGZMTn3LhljEi6h/2lMXH3NNBmusnIyD0ET78kI=; b=fmoy0rHPMQ2VR0qwdeZ3KruPXXixqZC3OASEcoTdN/qufz0cJWBDP4olQkP5bux9wTwPoGmGidGEaiqBlAkLMxJ1myqqHMsQW2weHP7CC5nEySuLF/u/N1NlIzntXPqGsXl4SVnBw/x0ZHxecoGoKdvNsEfCmbIsTkv/qlZwrD7IIT6tHlPHCAcu7malUCIfOd0+dfQQtMJxMPPA9J7Qu90+NncB+KkOJISEWwCj+bEV9g6jsvs27TdD55twb+DCP4vpTL771JerzYYnCPJ8lVMLNqkIcLfabp1AcAl3X5CQbio8BcKNFMgEgtsZofjG+lFChIbjOUwUBP73o6vglA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=henningkrause.eu; dmarc=pass action=none header.from=henningkrause.eu; dkim=pass header.d=henningkrause.eu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=henningkrause.eu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UdbfvGZMTn3LhljEi6h/2lMXH3NNBmusnIyD0ET78kI=; b=Va0Qce/pe6/ZfbRMw5LUhDw6LalGTCox+r4UEcRMdNh3wqdhYiWU8vOR7lllf9hpcfHhxWs/p+sEHA70C9Qx/HSXOcS8kKdpi3RAiClXeqpixUGwuShM/vjtI3Wmr8T65gnJqeerFjbCheApTbHH3Rpsc1iRk3AdslRQJrTAk4k= From: Henning Krause To: Benjamin Kaduk , Henning Krause CC: LAMPS WG , "Cooley, Dorothy E" , Deb Cooley , Michael Richardson Thread-Topic: [lamps] WG adoption of draft-dkg-lamps-samples ? Thread-Index: AQHWsrQREl/KbJsyWUuVKyLgcBjGB6m4Km0AgAAi/QCAAByBgIABN1CAgA9/rYCAAGeH0IAA8yMAgAADSEA= Date: Mon, 16 Nov 2020 08:29:19 +0000 Message-ID: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <20201116081422.GR39170@kduck.mit.edu> In-Reply-To: <20201116081422.GR39170@kduck.mit.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=henningkrause.eu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33bfc10d-5444-4d33-88e9-08d88a09b65c x-ms-traffictypediagnostic: DBAPR08MB5655: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qwx6Abhg0fLg7H55vE2o2GB3X2HF/ogp1uY4CnhvGcLuKH9Sn/bmSXygVFYKQI1CRxO5NeqgJ2N+KhFCJ65L09Xsw0wbOabZDoB/WuTMn9WLQ7qi6Mh+EoKhGTnjrda0Nh4QEsaE7+WJ66fz3LrSeMfR5f6eUFVOhuhBXPnqU0EPDRSiJDNLvFcWFVTmNyaU6zAmFEu5uRDhYkIPzE19B/1PyMmX55K7INTzFmUNesSO7KVPY0Hq/DaDQVkHQ1wrik2VpwT63O/uxML3Y/rLvrKYlHAaVyMJASO8aAafV33lZFJsbw40cpJDVHOd3bsH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3498.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39830400003)(376002)(136003)(346002)(396003)(64756008)(66556008)(66446008)(2906002)(66476007)(66946007)(76116006)(4744005)(7696005)(186003)(52536014)(5660300002)(33656002)(110136005)(54906003)(6506007)(316002)(8676002)(8936002)(55016002)(9686003)(71200400001)(86362001)(478600001)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YWzCN6eR9qolr8ZkUi6DH7+8PCvJOZtQ+6mO8vb5W6fNLDTocKsskiONrajfo+0LfDdjqeO8fHN/KYEnysziEse9Yfg5NC7fi5x5RR2flCa/6HyyI2N8+8cV0HaImRdRNamAxN99ZwEjOkJnQ98WqMUygnzyWs/bZ8QDBKVJr63k/KRuurZ1sZQ6qxMK7B4Rtq30Vhv6/d49S39p47/VkPxO0NXWrlL4rXrUfg0jRT97iEiSIZ3p2yMhTvEtRXPB2S4Agd33egrwzLl9zilXy4XZqt6NlQFh9h/gsfhoNcwQj+718CfC/hmciLNlCivu8zMxCV9AChfNRP5PkFFQyOarz4iHz6Rig/mmsRJKx0Ol7Z3BCWxKEvFB8Gnj/0xIdune6rvX/0CgyqbV5rk5h4MEHtx+lSxc3Y1JSBKWCJeuyp7Wtb7Y25DxRTHxyOLNhYuFFYiGVljFG9lDjDDCBlR0BS6adQp5FRWPtUoSt4nWCxfcgDysA5CrzM442FNhFvRbkOX1jYwF5jCULGA5TCh9kqBmdC9/+8r30aXQGw1aDk1MfPO9EJAYGzE/ImIHPEjFVq6mQl/lIg1SH4MSVS/qp13EAzHzYk6Weqg/bwOKYYBXwGS1Vjch5Ern3kRAS06D+yBM3oqAhE3rP8QgEyWuWgicCOESDbkqvTDo5ZeXFj+wIplxp4XanceovhQAf8QTxXugqzoTBl0n3ejucoa0iNrCINiMptqDM25Y3PMfTiaRTPCmtHyxnGiq+mhGJGIBNXNABBA+JGuaR7wPbJm5qwbplro3azwHNG6BLJQyELPz24THp2IymlGg0BQnCrndv6UEjKSK5fGDDgPKPdhQuCqwCLHNLr/h7oeE/DdYMyLVpuqHWGcbrKSiQFm3BMN9sxGcReKLwYWwlcoVvJYPPe14YzE4rOubfnXxG6cLnuaE0bUGbVp2wItFQb+L x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: henningkrause.eu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR08MB3498.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33bfc10d-5444-4d33-88e9-08d88a09b65c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 08:29:19.0652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2041dc2d-8eaa-4f51-96a8-b4923f969cba X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iUeErZpMnOvKdgAA7WDISkhuWEer68zNbDnAa1I9GIjmckCa1xI2MglevqcIwN8czlMqFQhP5b2kcTaXf9lrDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5655 Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 08:29:35 -0000 Hi, > I think OpenSSL is not supposed to do that, and furthermore I thought the= re > was a bug report on github about OpenSSL doing so, but I couldn't find it > quickly if it exists. Is there any written statement about this in an RFC? Because applications a= re going to implement this stuff and CA will enroll SMIME certificates usin= g ECDSA keys, they need to know that they have to enroll two certificates p= er email address (or add another key in the first cert - I think I saw a dr= aft for that on this list). I fear that unless its forbidden by the standard, people will implement it = this way. Kind regards, Henning=20 From nobody Mon Nov 16 01:12:10 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743453A1614 for ; Mon, 16 Nov 2020 01:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 0MQR-fDBcICK for ; Mon, 16 Nov 2020 01:12:08 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 3093B3A1611 for ; Mon, 16 Nov 2020 01:12:08 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id g19so15269537otp.13 for ; Mon, 16 Nov 2020 01:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=q4yKkVQI38aGS1+e6WMwJ2G5+t92/GxCpdJM10bj+F0=; b=p8G3H0EgCVC1HA1mipSLdFymF6grVanZH06fGQ/jfNluzQwG5ta2oGQLIuiF+71coS SIryWpySd5EB6OjACC0mcLEhhdfEAIHmsvFbOLRgEhodkhFcrmmQ7BKr7r1q9q6QEcHU yNSzT7srIe1ShxNqepKj1Ld43XPcrcLoQmUjxGPfo+7gMvguhMI0YwMphJZX5ReK6ocK nTXR4dyJECzq0JjOFmsMEatniVLUq/LjXYr7kpxD8mduA7lnxIC+8S79RSg/g0P18NRx GC0KGFP4Rr2rA/mLBrtU5a3XroW535eaEN7E6hyv9ckwD+1sN5XhdBGd5Yam69Dw7C9R d8qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=q4yKkVQI38aGS1+e6WMwJ2G5+t92/GxCpdJM10bj+F0=; b=rPYm4xMTCu6DkxqiOGmnTRCW/yasArA37Z5cnnqMI2I2LboP13v3WMFvgZppH7eqMG H1mhzsLU+G4FbJAVTMpcaRF7DZyvgdPiGAH5c4ltkJ1qlTf8Mkx69ASs0FARLF/nBNFP ghymxnDBEkaDwo7fCQUgsWHx2YCYpAoZGo+9Rx3cD0TQJ4JEBzci/xcWrATPFKDdEMBt jC8965Nszm2FAeys/1AfZ+ctHey/RlDr3xIWIHWcS6r36po5bKr8r8CfZx66kBM2nPYL twbx+8IrDcmsJtxpA0LB4npL3L/HNTM48DohiPIKmhtsL9bKale/17vctA78qrBBlYOG wxYA== X-Gm-Message-State: AOAM531kPTJlD0cbK6dBDOfeo0QAABsADmsVZrN9mHIN9rzhD7/euXVy RnI3DSn9H5HRmtGpGPt0EhmGhTG/z6nBHKsg8a8= X-Google-Smtp-Source: ABdhPJxetNUvbQeJRjuPG6xNS6mkF/c2oyTRInh50qjnjQyZI76jclEPn4l+LFgf3MgDYuF6rGVIwWLGJKJ1qP8RCas= X-Received: by 2002:a9d:649:: with SMTP id 67mr6220897otn.194.1605517927420; Mon, 16 Nov 2020 01:12:07 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: From: Jonathan Hammell Date: Mon, 16 Nov 2020 04:11:56 -0500 Message-ID: To: Henning Krause Cc: Deb Cooley , LAMPS WG , "Cooley, Dorothy E" , Michael Richardson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 09:12:09 -0000 On Sun, Nov 15, 2020 at 12:50 PM Henning Krause wrote: > > > -------snip-------------------------------------------------- > > > > > I have no idea how ECDSA works with S/MIME encryption. > > > > Does anyone have a suggestion here? Is anyone on this list using eithe= r > > ECDSA or EDDSA with e-mail? > > > > -----snip--------------------------------------------- > > > > I don't have one (and I may never if I retire before US DOD moves off o= f > > RSA2048) but an ECDSA cert would be used for digital signature in S/MIM= E. > > Encryption would use a separate key/cert - not ECDSA, most likely ECDH = with > > a semi-static scheme (sender is ephemeral, recipient is static). > > > > I've created an ECDSA certificate using OpenSSL and used that successfull= y to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for ECDH. = I've also created a prototype in C# to the same thing and was able to decry= pt the message created by OpenSSL. > > So creating sample certificates is relatively straight forward: > > Generate key: > ecparam -out ecdsa.key -name secp256r1 -genkey > > The key can then be used to create a certificate signing request and the = actual cert. > > The encryption indeed uses an ephemeral key for the sender and the static= public key from the recipients certificate. > > @Deb Cooley, why do you say you would a different certificate? Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both signing and encryption and gives several reasons. RFC 5480 does allow "any combination" of the key usage bits digitalSignature, nonRepudiation and keyAgreement. However, note that RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC certificates (i.e. with algorithm identifier id-ecPublicKey). Jonathan From nobody Mon Nov 16 03:09:52 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0687F3A09E5 for ; Mon, 16 Nov 2020 03:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=mS1u8f/0; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=i07odIbQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h90nYg88YWYt for ; Mon, 16 Nov 2020 03:09:48 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CA73A09D5 for ; Mon, 16 Nov 2020 03:09:48 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605524983; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VPxk8NY5UHtShehIVtyediVh2pMKYR3gDwQl6lyfNZg=; b=mS1u8f/0SQRwMDTHyxUuKtvuakv4rQ/71E/ICjblWqJ/MmkDqWVoN0Q35HBc30rIfcHLm v50fM7Ay5p0ZfLMDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605524983; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=VPxk8NY5UHtShehIVtyediVh2pMKYR3gDwQl6lyfNZg=; b=i07odIbQEOjo5bOscdTh2qpZCrIB0+GC8RQouB55p+/uB1+ajVun7AfRCRhE3Z8lL+oMB EcUbBwKz3H3Mw6AKOffew1oGU7EkgqjRcwDXCmcymHH0TyR7ijs0eAz6jTVq4tsb9T0TRXI lxGuf5Z6JWY7s68Y7g4DAIDGJphcbprHCD6btF04unHHdAGeWmpyKiursXB9D/2bd6SGUCU 46/ReMXkf32ZaKxCtP93lWUqm96BpUkpDU6aH/QWj3iuVAJbHiB3slAK1gwXdAzZVMihQrz HmHh16PUy+Rf8Sm/dl001fjEi9YaPFoLVpooyro+7B12jIE0ziEmr3vaqZwQ== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id F1173F9A8; Mon, 16 Nov 2020 06:09:42 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 958A820544; Mon, 16 Nov 2020 01:16:54 -0500 (EST) From: Daniel Kahn Gillmor To: Henning Krause , Deb Cooley , LAMPS WG Cc: "Cooley\, Dorothy E" , Michael Richardson In-Reply-To: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 16 Nov 2020 01:16:53 -0500 Message-ID: <87pn4desh6.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:09:50 -0000 --=-=-= Content-Type: text/plain On Sun 2020-11-15 17:50:34 +0000, Henning Krause wrote: > The encryption indeed uses an ephemeral key for the sender and the > static public key from the recipients certificate. Does this mean that if i can convince the certificate-holder to sign a document of my choosing, i can convert that signature to enable decryption of a ciphertext that was encrypted to the sender? Reusing the same cryptographic material for different purposes seems like it raises new cross-protocol questions that are potentially ugly -- isn't it safer to just avoid those risks with single-purpose mathematical objects? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7IZVgAKCRDEDyVUMvKB DwbAAQCFRHEotZJbVnUJ4pACw7KHqCYDlgp4cz+rEZVzw8Jw/AEAukE7X2xDpqDF QF3+BxeBuZ4+7ysImFgPi8cSkyohDgo= =TnCz -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 03:09:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1302D3A09D5 for ; Mon, 16 Nov 2020 03:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=+RwML9wB; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=rrO3FLX4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DYD0CrsT-IU for ; Mon, 16 Nov 2020 03:09:48 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F743A09E0 for ; Mon, 16 Nov 2020 03:09:48 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605524983; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Dmz0AB67nWHk4Sy9qHqswA3MUVEZZdw98IcQtfl1Ayk=; b=+RwML9wBG9R8RPFj8CTnF213nh3cIboKoaqG5mQ3kUigS5oXpBHoJ2K6ADzWCSl8o4sOF hL8VlLBNAOnqq54AQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605524982; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=Dmz0AB67nWHk4Sy9qHqswA3MUVEZZdw98IcQtfl1Ayk=; b=rrO3FLX4lo3RObqkadVFjlX3LIW+Mj1PS5hT7QO7bXzGhOywL1/3neqySn6v6xW+7nP0M vJYSV8Z2eXgYs9+rUd3Ly/sn8JWe8E3OYcc7zQty/kl4zgi9tCKmBa5ANCuAqG5AkfGDui3 VbiWkHxDgQDdXk0He3q3pqzpZ0aP8y6WDLhV+9wkhvQAvn/TEH2lmcZP3sAEZJdSECfLt+b MyXP2I3UdH0YcXEvUEiEpPoiZzcpEfgKmqdTt1e2EcJgbTMK/D+m86FVTTUsEBQvg9Qff3d CWk88z8VHY3gluWOkF+W2+VEnXNV0d4sJJ99jyZER0+AFdg4/3NEu2bUJh/w== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7344DF9A5; Mon, 16 Nov 2020 06:09:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id AB608207BB; Mon, 16 Nov 2020 01:19:39 -0500 (EST) From: Daniel Kahn Gillmor To: Deb Cooley , LAMPS WG Cc: "Cooley\, Dorothy E" , Michael Richardson In-Reply-To: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 16 Nov 2020 01:19:38 -0500 Message-ID: <87mtzhescl.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:09:50 -0000 --=-=-= Content-Type: text/plain On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote: > Encryption would use a separate key/cert - not ECDSA, most likely ECDH with > a semi-static scheme (sender is ephemeral, recipient is static). Thanks for this suggestion -- how would this separate ECDH cert be distributed? the signing ECDSA certificate is bundled with the signature in PKCS#7. do we just stick the ECDH cert in the same spot? do we need to mark it for purpose? if so, how? is it directly/explicitly tied to the signing cert? Sure would be nice to have some samples to make this clear :) --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7IZ+wAKCRDEDyVUMvKB DwR0AQCoJdHr64iXRk8fdYumw6ksNqY6jMhEPgJVPZgUAGpjrwEA/qyyNeJt7mhu ZHK3WVmK+7Eijuuro/DpVVa74KzgXQ4= =pcPO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 03:09:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B3C3A09E8 for ; Mon, 16 Nov 2020 03:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=KBlu+dOW; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=cbQsNw8j Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIoxhORoZRpW for ; Mon, 16 Nov 2020 03:09:49 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91123A09E7 for ; Mon, 16 Nov 2020 03:09:48 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605524983; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2Alp2QIKESfJ/sEk74bsKitr5+ssUQJzcdAegeeCILc=; b=KBlu+dOWzvcrtxAPdsh9KSPAporv0yvw+sNlz/TwwnFzQNTuc+m/9RE/oN+j8f7zmNfo4 5TRMjZqnBZvdNiOAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605524982; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=2Alp2QIKESfJ/sEk74bsKitr5+ssUQJzcdAegeeCILc=; b=cbQsNw8j8qKuWUarNMiE3YinoDq7rhRyrWYXvKp4qo2LE9L5pteClVrgVSUHTkE9YltR/ K1MSXd/Re4zwd3dlUu8JIfAZxOU4mmiGVoxc0tTQjlIcpwdG1X0QZUTczBHJiCUkBqLqU1O W+PM2Qot/ZDYvwHXmCvnDCe4UgP1SCvSWifQU+Fw2tHA2IgQYHeyuxRnQX8vnqSpwa6f6/C /YB7cYcvBx8UnWWnQAbTQ7NnXXJYsG9uiMLS7oYgEdYXUQzynzXwz42XNgr0lQTPRWdVaaC gFPpOf+RN6XW3LgNi8CEvRyZs2v/6oMA1QR8BxXPs6kydATIIqV5fHkSyBtQ== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 71F7CF9A7; Mon, 16 Nov 2020 06:09:41 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9A9152098E; Mon, 16 Nov 2020 06:09:37 -0500 (EST) From: Daniel Kahn Gillmor To: Ryan Sleevi , "Salz\, Rich" Cc: LAMPS , Erik Andersen , Russ Housley In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <2FFE0666-7A41-4480-A609-58CC0E6B1373@vigilsec.com> <1DBFA835-E407-42E1-9DD4-C6F4CA719946@vigilsec.com> <18C79F07-97F3-454F-BB29-CEA2E78106AD@akamai.com> <45D17BD8-263E-4B51-B77F-7B2E02B80B3D@akamai.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 16 Nov 2020 06:09:36 -0500 Message-ID: <87ima5eexb.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:09:50 -0000 --=-=-= Content-Type: text/plain On Sat 2020-11-14 15:04:34 -0500, Ryan Sleevi wrote: > you can already accomplish that with existing capabilities, so there's no > point to standardizing in the first place a feature that would be > net-security-negative compared to those existing capabilities. As the person who raised this question about id-ce-noRevAvail in the first place, i should probably say that i started off with the position that Ryan Sleevi has here, and this conversation has only reinforced that position for me. I raised the question because i heard from another implementer that a cert i created that had no OCSP and no CRL was failing on their system because there was no way to verify its revocation status. That other implementer suggested that i might want to look into these extensions to bypass such a check. This policy (of requiring revocation checks even when there is no indicator in the cert of how to find them) surprised me, but i was game to look into it if it made life easier for other implementers. Now, after learning that neither of these two standards (no-CRL and no-OCSP) are well-defined for this particular use case, i'm even more inclined to think that that local policy is simply a bad idea and should be discouraged, rather than changing any issuing policies. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7Jd8QAKCRDEDyVUMvKB D1u9AP0boDClzJxUAmPWtuFNALuc6Myo3i38FcuuONk/TQjxxgEA3yXhSln4HxZd 3Pn4kndlOYupE4mLzPOXjg2S6M/q5AQ= =jrIc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 03:36:22 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917A73A0ABC for ; Mon, 16 Nov 2020 03:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pE4aCSG256Ad for ; Mon, 16 Nov 2020 03:36:20 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C753A0AB5 for ; Mon, 16 Nov 2020 03:36:20 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id t143so18383655oif.10 for ; Mon, 16 Nov 2020 03:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pnvgd3cix2hHAPEjNy/Vr6PxCq2MKWRQM+qwNKDz6Eo=; b=VAICXWJRHWzwja3csFoEnRP5KfyGAIt/EuQH+c9fR4qPgdxTJ5YbsHpIXJS3Xt9Ieh JjMouEC+WHMB9TiSzoRxQf8rTnfrG16mTZFbyEPsIpVdjA571q8prmD/yDRoy54oKD4r bcicnz0ib3JGj5Z01imxGUrWYN7DtjeAfXNoIyOovSCPdmj6/m7x4XHl4p23c3Znz5Hk 5cLy7ByH2b142fhPzoZ0xMBIyf/Z2Hf1FSdHAfYstbqQqMBqts2RzOiyh3fh0+zFDtWX 9HkDct8j/lpELwYYQy/2VOUQw1jCiTZh/+3wQPrGrN/+Ep8tHIPhqv5+Etd3Iz9DYkzS ifMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pnvgd3cix2hHAPEjNy/Vr6PxCq2MKWRQM+qwNKDz6Eo=; b=bnNVMuoUawwyaM8qEw7DhVumc6qrQX7isHfMLdI7R89OY43JkFn4NcHfJT4vL1SOyQ L0/Hogf8vpJyoEdFvXl3Oca0res2lsN6XctTmm41EewHtxMvcTwjNOk7cGT2iahcBa+1 tdvgnp0D9ouOkokJBafOR406ULJiMkuf5OxCtN1WjzlpsTLvh3aXAxcq9kxITzYkMhRq PrVi6E0lb69iYB/P/EfgIZfBvF1q7euNYB284Rqn9qlVDXLivmysEfS7BTRHCF86YFK6 n8PlzidCvQzRvnhb7+JayoUFZRV0INEbm2684MUlcKGwUCqmXTu6sQ0+VXoGXccWpU7P eSig== X-Gm-Message-State: AOAM532xrQ9g5VacXD8YrhFCo5Dbxl4cSJBnHYi3OqGn+UAk9cKmFCez jJxWjgDU5x1DvQaU2GV7kGTeoovx1dqQiXW2r7Y= X-Google-Smtp-Source: ABdhPJwdiR3q8ahi8GqC/itVCh06doBvr8WyoehqWaYc7tM4z7Kf/C6J6Q1cbl8TRxWPIRnVf9o5nYme2Gs4dUnE7k8= X-Received: by 2002:aca:3115:: with SMTP id x21mr8923603oix.101.1605526579581; Mon, 16 Nov 2020 03:36:19 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <87mtzhescl.fsf@fifthhorseman.net> In-Reply-To: <87mtzhescl.fsf@fifthhorseman.net> From: Jonathan Hammell Date: Mon, 16 Nov 2020 06:36:08 -0500 Message-ID: To: Daniel Kahn Gillmor Cc: Deb Cooley , LAMPS WG , "Cooley, Dorothy E" , Michael Richardson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:36:22 -0000 On Mon, Nov 16, 2020 at 6:10 AM Daniel Kahn Gillmor wrote: > > On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote: > > > Encryption would use a separate key/cert - not ECDSA, most likely ECDH with > > a semi-static scheme (sender is ephemeral, recipient is static). > > Thanks for this suggestion -- how would this separate ECDH cert be > distributed? the signing ECDSA certificate is bundled with the > signature in PKCS#7. do we just stick the ECDH cert in the same spot? > do we need to mark it for purpose? if so, how? is it > directly/explicitly tied to the signing cert? > > Sure would be nice to have some samples to make this clear :) As Deb said, encryption with ECDH is typically ephemeral-static. Therefore, the ECDH certificate belongs to the recipient and the sender just creates and sends an ephemeral public key (i.e. no certificate). In the KeyAgreeRecipientInfo, the sender would put his/her ephemeral key in originatorKey. The recipient's ECDH certificate is referred to in KeyAgreeRecipientIdentifier, but the actual certificate is not sent in the structure since the recipient only needs to use his/her private key for decryption (and likely has the certificate, anyway). In practice, when a sender doesn't have the recipient's ECDH certificate, typically he/she has to request a S/MIME signed message from the recipient, which does seem to include all certificates (signing and encryption); but this is the same as for RSA. Jonathan From nobody Mon Nov 16 06:24:39 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBD03A109E for ; Mon, 16 Nov 2020 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 I4U6sEvdoQ1D for ; Mon, 16 Nov 2020 06:24:36 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB493A109C for ; Mon, 16 Nov 2020 06:24:35 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id g17so12924764qts.5 for ; Mon, 16 Nov 2020 06:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=/bYSU5tZhF7v/JnOsAdQvSrq5/EYvx0fOc3BIc4GEec=; b=eEH8IKzqbEIuAmbK9CEbvhrNLMKVb+2XX7qYHVmwxz7SyKwh0qDDg1kqFCVh1ufoyc 8xCKJfk1DjPttJc9GpQuMiEZzcIEntkzQp7q9IXDhZZuYGKy92pgbA88LfuhJABAaai0 /km30G87SYHhgwEXguP2Ed5+JE0uYauyqmRwFkFaRok+P5rjvMj5BTfHr3BCoRbtCZxZ xVURtb9a8ZjhFH/7AyiJK8OIikjlfSB0EaqYVI0Ls9M24OcgobGeLWW/w6+ef0m7VIVP uov69DHKkYaCe25/76AgU/RtDoxUH4XD+35tGImrYovZHJZcj+6gYyZqpuO/TkbntbX/ mmHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=/bYSU5tZhF7v/JnOsAdQvSrq5/EYvx0fOc3BIc4GEec=; b=Un+FpowAi1CEZCZiiQVIz3PFH40MZe+UMXPwJrOhD7k+6sX0+Xf1O9u3j6WujlxVnu O7v+RvjoNo7bvwO33Ouksb8zgvOvI7IKYocpshhX6pUnW/zhenBrYUeAVXH9Vr0+yaYf rTE7Cx9q/nw+CsH4+b5n90WLOWrvrkfNTmWDvrY4iZM7hWQ5XtfRvKpN/DBdspLOCVUk 3mMsd8cPwfOu/DwlFdpEZqIECOXKET33yBXidk/kuC+rZ2uw7lP+0OxPDG8tae1m8UWB W6qMrL0qqjhFEaM3zZQvY1tTl7agp4P+esg3gsP2lOpZ3j7O+B9ZCcdUyzFNieFTD8KM ffYA== X-Gm-Message-State: AOAM532shVgsp++OQjj2MFiCbSXNnhNCC7SfrJu/l6EmoxsLdR3sMrFg z5iv9rLS6wC7/8+hiwisMcPSeHIDv0o= X-Google-Smtp-Source: ABdhPJyYnAOCJYKG/PvuXNGICCMZLE0mI5hcOX2svMEw9y/nVxVqXcti0/inUS/bfprSY9k3gh8hTg== X-Received: by 2002:ac8:594c:: with SMTP id 12mr14269037qtz.224.1605536674537; Mon, 16 Nov 2020 06:24:34 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id z16sm13139741qka.18.2020.11.16.06.24.33 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 06:24:33 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS WG'" References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <87mtzhescl.fsf@fifthhorseman.net> In-Reply-To: <87mtzhescl.fsf@fifthhorseman.net> Date: Mon, 16 Nov 2020 09:24:32 -0500 Message-ID: <0b2301d6bc24$3440b9f0$9cc22dd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMGb7PLGIUkstBph5ynWWmikEzkwGcA6vJAUgCblYA8vKfOwG3tgbYAqF2tfQBzG4lI6kQLqwg Content-Language: en-us Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 14:24:37 -0000 Encryption/Key agreement certificate distribution problem is not unique to EC. We have the same issue in RSA. S/MIME clients can be configured to send signer's encryption/key agreement certificate. Absent a directory that is how certificates are distributed by the users. Key usage extension and SPKI algorithm dictate if the SPKI can be used as a static ECDH. There are two ways to do that. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Monday, November 16, 2020 1:20 AM To: Deb Cooley ; LAMPS WG Cc: Cooley, Dorothy E ; Michael Richardson Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote: > Encryption would use a separate key/cert - not ECDSA, most likely ECDH > with a semi-static scheme (sender is ephemeral, recipient is static). Thanks for this suggestion -- how would this separate ECDH cert be distributed? the signing ECDSA certificate is bundled with the signature in PKCS#7. do we just stick the ECDH cert in the same spot? do we need to mark it for purpose? if so, how? is it directly/explicitly tied to the signing cert? Sure would be nice to have some samples to make this clear :) --dkg From nobody Mon Nov 16 06:31:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC053A10CC for ; Mon, 16 Nov 2020 06:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DdBUOo6T6VkN for ; Mon, 16 Nov 2020 06:31:29 -0800 (PST) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (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 315643A10C3 for ; Mon, 16 Nov 2020 06:31:29 -0800 (PST) Received: by mail-oo1-xc2e.google.com with SMTP id c25so3926959ooe.13 for ; Mon, 16 Nov 2020 06:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HWEoKOqkskR3vry/3+Urzkb88wyafPngwucy/8/SJqI=; b=lctmk1+LLYnDurOFmhlvbfB3De9wuLYbX169ftVmsh1zvM/ofX8RIhKy8PDPloMRvx HL6S44ZdGmwYiWbpi5mAg7oxjFZ1M5sOHVcpFBZUdc8ngBEhgcBgHUU+vUuW5SCRG69l MeEqGN5qk87Vc2SacmvzjOQVllvvQMeMIxqs/x30udLqDZLR5f0Q7otcXoMMol2yp27v fy5s4sprm1E1KCPsgaUQ/7j+AzpnR/yI6P3mTjqyZ2iC8ZtcM/+mT6SH6AL5MNvNYtJC gSg8fcnDuYd6ipgMDpznGEuEYmu0Rzizpv5I4QpP/FAdE1Le//Eyi29npUXNpZVZc/6Q ExTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HWEoKOqkskR3vry/3+Urzkb88wyafPngwucy/8/SJqI=; b=j/laOMjvEs22me88itBMgHIPP9sBJyD/ApC8ornX/MGIiFB3JZZA8/SwYspSE43VN1 X7RmrszJr/mpnbz+u2yw8nria9PdM3Xcjiq7UHO09OU/pG8Oa0iCfmAMUypXLkX845U9 Ixk6HcRjP0pisD/UWdrrS5FK9Uo3xq6G2SbbP8d8q+hiTRMo9dhCH+SvgMI44x+v6EG1 +CNbSAIjMJcpaOp8Krj389FRM2WSg6QZqpt6/m/srXiSciN1D+ATx6ADN/BvnqBSKi4F y+uF7cV5aU3J42IiFINDuoE9C99odeMyijUZihY8/cKpN8y8O0DGjfGAbiCwCuJhpapk p7OQ== X-Gm-Message-State: AOAM532oYF5QiVEORqNFGH3Jsngk7omq1wBm4CYXT7Aao9vY7ET4NNKd u+nFnRXw/l/Fmoj4HBxRVxvJsGbTVB83A5/TjXl7hbcREQ== X-Google-Smtp-Source: ABdhPJwhmR/7Gb8jZJsfL//tLaZiB/AcxNmctSk9BFsjqQix2RExrSXAuzwE8cBQNKJjgRAk1aLc/CCJn6edwbLz0zw= X-Received: by 2002:a4a:d043:: with SMTP id x3mr10251888oor.19.1605537086545; Mon, 16 Nov 2020 06:31:26 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <87mtzhescl.fsf@fifthhorseman.net> <0b2301d6bc24$3440b9f0$9cc22dd0$@gmail.com> In-Reply-To: <0b2301d6bc24$3440b9f0$9cc22dd0$@gmail.com> From: Deb Cooley Date: Mon, 16 Nov 2020 09:31:15 -0500 Message-ID: To: LAMPS WG Content-Type: multipart/alternative; boundary="000000000000b7a38d05b43a3bec" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 14:31:31 -0000 --000000000000b7a38d05b43a3bec Content-Type: text/plain; charset="UTF-8" Exactly. To demonstrate using RSA, I could sign a message off of my 'for real' account. You would get both my signature cert and my encryption cert (both RSA today). This allows you to encrypt to me today, and it would work the same way w/ ECC algorithms. Let me know if you want me to do this, I'd be happy to. Using a single key pair for multiple uses (signature and key transport/agreement) is seldom a good thing. The NIST SP that Jonathan lists is a good source. Deb On Mon, Nov 16, 2020 at 9:24 AM Santosh Chokhani wrote: > Encryption/Key agreement certificate distribution problem is not unique to > EC. We have the same issue in RSA. S/MIME clients can be configured to > send signer's encryption/key agreement certificate. Absent a directory > that > is how certificates are distributed by the users. > > Key usage extension and SPKI algorithm dictate if the SPKI can be used as a > static ECDH. There are two ways to do that. > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn > Gillmor > Sent: Monday, November 16, 2020 1:20 AM > To: Deb Cooley ; LAMPS WG > Cc: Cooley, Dorothy E ; Michael Richardson > > Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? > > On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote: > > > Encryption would use a separate key/cert - not ECDSA, most likely ECDH > > with a semi-static scheme (sender is ephemeral, recipient is static). > > Thanks for this suggestion -- how would this separate ECDH cert be > distributed? the signing ECDSA certificate is bundled with the signature > in > PKCS#7. do we just stick the ECDH cert in the same spot? > do we need to mark it for purpose? if so, how? is it directly/explicitly > tied to the signing cert? > > Sure would be nice to have some samples to make this clear :) > > --dkg > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000b7a38d05b43a3bec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Exactly.=C2=A0 To demonstrate using RSA, I could sign= a message off of my 'for real' account.=C2=A0 You would get both m= y signature cert and my encryption cert (both RSA today).=C2=A0 This allows= you to encrypt to me today, and it would work the same way w/ ECC algorith= ms.=C2=A0 Let me know if you want me to do this, I'd be happy to.
=

Using a single key pair for multiple uses (signature an= d key transport/agreement) is seldom a good thing.=C2=A0 The NIST SP that J= onathan lists is a good source.=C2=A0

Deb
=

On Mon, Nov 16, 2020 at 9:24 AM Santosh Chokhani <santosh.chokhani@gmail.com> wrote:
=
Encryption/Key agre= ement certificate distribution problem is not unique to
EC.=C2=A0 We have the same issue in RSA.=C2=A0 S/MIME clients can be config= ured to
send signer's encryption/key agreement certificate.=C2=A0 Absent a dire= ctory that
is how certificates are distributed by the users.

Key usage extension and SPKI algorithm dictate if the SPKI can be used as a=
static ECDH.=C2=A0 There are two ways to do that.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Monday, November 16, 2020 1:20 AM
To: Deb Cooley <debcooley1@gmail.com>; LAMPS WG <spasm@ietf.org>
Cc: Cooley, Dorothy E <decoole@nsa.gov>; Michael Richardson
<mcr+ietf@s= andelman.ca>
Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ?

On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote:

> Encryption would use a separate key/cert - not ECDSA, most likely ECDH=
> with a semi-static scheme (sender is ephemeral, recipient is static).<= br>
Thanks for this suggestion -- how would this separate ECDH cert be
distributed?=C2=A0 the signing ECDSA certificate is bundled with the signat= ure in
PKCS#7.=C2=A0 do we just stick the ECDH cert in the same spot?
do we need to mark it for purpose?=C2=A0 if so, how?=C2=A0 is it directly/e= xplicitly
tied to the signing cert?

Sure would be nice to have some samples to make this clear :)

=C2=A0 =C2=A0 =C2=A0--dkg

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000b7a38d05b43a3bec-- From nobody Mon Nov 16 09:24:06 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867CF3A1327 for ; Mon, 16 Nov 2020 09:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=henningkrause.eu header.b=xMXf8PdG; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=fYFcqZ+/; dkim=pass (1024-bit key) header.d=henningkrause.eu header.b=pkHIJCk1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s3SPaIaFfSj for ; Mon, 16 Nov 2020 09:24:02 -0800 (PST) Received: from de-s01-gw2.mail.cloud.nospamproxy.com (de-s01-gw2.mail.cloud.nospamproxy.com [193.37.132.171]) (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 72B4C3A09D1 for ; Mon, 16 Nov 2020 09:24:02 -0800 (PST) DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1e; t=1605547438; bh=RlMn7BubeZwtuqdjWiKLHzBfCKVR3AmtChyFspT3YpY=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=ed25519-sha256; b= xMXf8PdGDeri3C8I0jCaW72cqcbkKBQjxnQqyjokKv15bLG5KuxgEcjhRot114aVd1a5A0+DY7Pu7KyArOutAw== DKIM-Signature: v=1; c=relaxed/relaxed; d=henningkrause.eu; s=dkim1r; t=1605547438; bh=RlMn7BubeZwtuqdjWiKLHzBfCKVR3AmtChyFspT3YpY=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; a=rsa-sha256; b= fYFcqZ+/zj6kukBAqO7FVmqgzlJ5oqcHkLG6cs0wPryGFTPmqetyvFObIpupzWOzxrvMFEoTen8+s/CHReNzKUxgUT9uu8hQxP+yXJV7/H3W0vbzmF/6+AR/WVD7xScOv62dh/emQNfswbt52x2q/g/DnIueqv3mxovn66ccjDM= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F6afmvv2GG0x2G6o2NEp02udr59V3ZgLWFEpIvKE9XwYCRMHMDxOTJbOXQddOXkGUFQ0YzxPdQs3l5Y7DCU5JAV0iDP36lPbTSsLRq4GQPa5ZfYNnXLju/ODRigePkTg4389I2WdUuHpKzp6yqPns1a628vvZwD6N8SaiMXKGOZG+oMk6wQ90KHt2iATQvk1wfu6y/17sW25xD+LKRNxl3xrmwooctCmsCw074Ej25n2pJ+t7gM8NQ4oU0EXd2SBjEH9sbHbU7FjtQUHME75zZPXBngQO3wzlLdFkWR5XO+jmpJrxWy+fRsF1fn6HhQoLRUYFhk5L5zE/srVsiiqMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RlMn7BubeZwtuqdjWiKLHzBfCKVR3AmtChyFspT3YpY=; b=dS/jwKfLKye8riLekGoXGvERWl7MufytnXHUisCeYZpTtg2VKmMR/Vx3+IkUkPyzXsWDexJhqzKGCRsamYJmE0Wz3rCSQJTAiU4QTPlSTsHCRMkhWdbE/oMaX97gU9om2m1vhJsnSVX7cvNVkxHktvgTSdNQFj4yPlQWy2ajDIXbfx/aOnRFdZlYGGTAqVxaBH4j9Hp5B/R4KwjmM0txfc/EGszPHppeRJ2rdsWvJc6rOfIb/7pK+3Ad9JhOHRol83ssDNC/rNXFubAibtXpAIarxaGOScpxfUCOc/ZysEdXfUqMPrLI7FUvzR3RmFhbzjoqRVGSr72NFQUcf97SAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=henningkrause.eu; dmarc=pass action=none header.from=henningkrause.eu; dkim=pass header.d=henningkrause.eu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=henningkrause.eu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RlMn7BubeZwtuqdjWiKLHzBfCKVR3AmtChyFspT3YpY=; b=pkHIJCk1Ou7JliAuNy5jcskGqYtnWgxsJstNAvkDK35JaCS5ScTeI7v5xF1Qfxee3K7wa6HhkNVdGjNfkxWd++gcUJ8lN0xRFR1VEpM8KW5FIVRCCTB4ZeQ8SRZcvdjWXDWmGiVRECL0RhnInDVlDcjAx3zY7VM/9cvCS5Sb9VU= From: Henning Krause To: Jonathan Hammell CC: Deb Cooley , LAMPS WG , "Cooley, Dorothy E" , Michael Richardson Thread-Topic: [lamps] WG adoption of draft-dkg-lamps-samples ? Thread-Index: AQHWsrQREl/KbJsyWUuVKyLgcBjGB6m4Km0AgAAi/QCAAByBgIABN1CAgA9/rYCAAGeH0IABAzgAgACGBaA= Date: Mon, 16 Nov 2020 17:23:54 +0000 Message-ID: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=henningkrause.eu; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41f7b178-87bc-4921-f71c-08d88a54651c x-ms-traffictypediagnostic: DBBPR08MB4758: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qLU6z6ae1cqA/CNzPvoC+DJJrFL9rmAlOYlc6bLkYnIVcn8JctGXHJiyACw+zYMOnUOuxX868d0VrrB+ZNDN8om741lWu1KsYiAi3JV6YcHmDNo3ne9YafU6qCWekFU7pETPEOv9xtxr5Iz3hJLTX0EPei9nwkLx+gSKLJ6VYANMe7Hd3UwaZ4OFMdJQEVj5lcldG5I5tHPfVWppc3rdpMUYRlodR2n3gWwFzqCPU99ITuDrKikavFlXwe6JsGw07xBMmUe141PyJgLJpJwUhfbYSOwU/W7wF6HwlxOolH3cP/e1N4zrpNdGWap+/0BVJ21SHmVgGF4/UOd6/QbUCA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3498.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(39830400003)(376002)(346002)(54906003)(2906002)(478600001)(71200400001)(9686003)(53546011)(316002)(6506007)(7696005)(6916009)(76116006)(4326008)(52536014)(83380400001)(66446008)(64756008)(66476007)(8936002)(55016002)(66556008)(66946007)(86362001)(186003)(8676002)(33656002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cVdOTHhjVWtqQVhpa2VRKzNzYVNOakIzMlhCV1QvTGd3Qk9yQzhvVUo2V1dO?= =?utf-8?B?UHVlVGpPNUcvMWlYRzVuYlRFYTl4a1RsSkZyMHFaOVNMRmxTVE4wL285OTNW?= =?utf-8?B?TVN6WXBDNFE4ZUxlNEpSRDVMcGJELzBvalFubkYxMU5HMWZHQWpwbnZJQ0xV?= =?utf-8?B?dmNmdkRHZjErek9Oanp2NGtvelk4R1EyanI0MzRnTUl1RmhxdHNBbURLRHND?= =?utf-8?B?emVPaEcrbmdRYmZ1MFhOelBvSHpYL25KM1luOXlpZjh5T3cvM0RNK2c3dTZx?= =?utf-8?B?c3Q3S2FhN0FENFA2bHpobHVkdk1BbHJ3cXc1WWZpdVdsWjVLcmMrcWlzeGhu?= =?utf-8?B?QlJ6cXNZK2RZUFR1T1ZmSWoxbjJiTzZtSS9BL3JCK2I4eHVHcVdHK0htQWZa?= =?utf-8?B?RkFMeHNuZHdncjBxb3NGVWtuaitMWElIQmdFRktzTXNzcUpoWk0rcTJLb3Az?= =?utf-8?B?Qm13TS84R0c0Mm5zb3ZjVjl4WE42TVg5WVR0L3lLQU5pUHVCdERTS3F6TjlD?= =?utf-8?B?blhkaThRQzZEUnl1MjgwT3JJZ0pBOVJLVnV1bTdjSko3eFRUVENJYlYvSDNR?= =?utf-8?B?Tk1GNzJMRmNoblZlTjhZZ3ZjU0VvaUtmTTlhT3JRTStpT1JNelpTeVhRd0l1?= =?utf-8?B?WUt5aEVQNllFNkZCR29DQlZxNm5ueFd5ZHBqeG5vOTVqQ05haDI2aGF0Qmdm?= =?utf-8?B?QzkrWVRKaU5aQUtrN2lxTmdPcWJhNHVHWVV3VHV3MjNyczZqVFlpcjVhOEdT?= =?utf-8?B?aWFMM3BMRngycFk1VFhoSW8veEluQ2F1anYxcWNlV0Z5WnBpVHZOaGdZWmRy?= =?utf-8?B?RVBGU1FacjdTNzdKc2lpUkFkK1VxM0JjK1pJTm1jMS9wbVBZZVYxczkwWmhj?= =?utf-8?B?WXZlSFRqbTJoWjhBNDAzSXJSQXpnSHBXbkkzM1ZlZC9FdlNUOGlEd2tQUVB1?= =?utf-8?B?TThUejRLSDZTTnFabkw2cTJnemtzTThyWGZYY1lIV3k3Q0N6TWxYb3lDSlh4?= =?utf-8?B?NmpaOUEzM0hGYjR3Wkd5WWJPN2dqM1VqejRnQTAxZnJabjExYjRrVmRlS25O?= =?utf-8?B?UDZDQkFRU1N2YWhWTVI1OFhzckpQakNqNmlqbUQzWVZaOUxHZTFpTjBEWCtp?= =?utf-8?B?MFhlOE54ZXlJOG5YRE5NNmtUakZGR3pMZnlpYlc4WnA5Y29ERmVvcVN5V1Iz?= =?utf-8?B?bHV6TXhmYkJVV2NMdjk1QnJIbVhYNU5lcGhsNnM1d1hYL0lsOEhsblRaMXVy?= =?utf-8?B?ay92V2gzK0NmTnJtVXEyN1VyT2UxY2FqT0RHRVhuUGQrVjNDQT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: henningkrause.eu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR08MB3498.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41f7b178-87bc-4921-f71c-08d88a54651c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2020 17:23:55.0558 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2041dc2d-8eaa-4f51-96a8-b4923f969cba X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OFm4ZKSNlo8bH2wcjnTs5YMmHCx7S1vz1vrVqiRZXI75g5ZHxX4F1+Leic2r47E5tV+5BpeSFxiTVAiVEBhZ6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4758 Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 17:24:05 -0000 SGkgSm9uYXRoYW4sDQoNCmluZGVlZCBOSVNUIHNheXMgd2UgbXVzdCBub3QgdXNlIHRoZSBzYW1l IGtleXMsIGJ1dCB0aGUgUkZDcyBhcmUgbm90IHRoYXQgY2xlYXI6DQoNClJGQyA4ODEzIGRpc2Fs bG93cyBrZXlFbmNpcGhlcm1lbnQgb3IgZGF0YUVuY2lwaGVybWVudCBpbiBnZW5lcmFsIEVDQyBj ZXJ0aWZpY2F0ZXMgY2VydGlmaWNhdGVzIChpLmUuIHdpdGggYWxnb3JpdGhtIGlkZW50aWZpZXIg aWQtZWNQdWJsaWNLZXksIGJ1dCBhbHNvIHdpdGggaWQtZWNESCBvciBpZC1lY01RVikuDQoNCkJ1 dCB0aGUgZW5jcnlwdGlvbiB3aXRoIEVDQyB1c2VzIEVDREgsIGFuZCBwZXIgUkZDIDUyODAsIEVD REggc2hvdWxkIGZhbGwgdW5kZXIgdGhlIGtleUFncmVlbWVudCB1c2FnZSwgb3IgYW0gSSB3cm9u Zz8gDQoNCkkgY2FuJ3QgZmluZCBhbnl0aGluZyBpbiB0aG9zZSBSRkMgdGhhdCB3b3VsZCBmb3Ji aWQgbWUgdG8gdXNlIHRoZSBzYW1lIGNlcnRpZmljYXRlIGZvciBzaWduYXR1cmUgYW5kIGVuY3J5 cHRpb24uIA0KDQpEaWQgSSBvdmVybG9vayBzb21ldGhpbmc/DQoNCktpbmQgcmVnYXJkcywNCkhl bm5pbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb25hdGhhbiBI YW1tZWxsIFttYWlsdG86amZoYW1tZS5jY2NzQGdtYWlsLmNvbV0NCj4gU2VudDogTW9udGFnLCAx Ni4gTm92ZW1iZXIgMjAyMCAxMDoxMg0KPiBUbzogSGVubmluZyBLcmF1c2UgPG1haWxAaGVubmlu Z2tyYXVzZS5ldT4NCj4gQ2M6IERlYiBDb29sZXkgPGRlYmNvb2xleTFAZ21haWwuY29tPjsgTEFN UFMgV0cgPHNwYXNtQGlldGYub3JnPjsNCj4gQ29vbGV5LCBEb3JvdGh5IEUgPGRlY29vbGVAbnNh Lmdvdj47IE1pY2hhZWwgUmljaGFyZHNvbg0KPiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPg0KPiBT dWJqZWN0OiBSZTogW2xhbXBzXSBXRyBhZG9wdGlvbiBvZiBkcmFmdC1ka2ctbGFtcHMtc2FtcGxl cyA/DQo+IA0KPiBPbiBTdW4sIE5vdiAxNSwgMjAyMCBhdCAxMjo1MCBQTSBIZW5uaW5nIEtyYXVz ZQ0KPiA8bWFpbD00MGhlbm5pbmdrcmF1c2UuZXVAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+ DQo+ID4gPiAtLS0tLS0tc25pcC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gPg0KPiA+ID4gPiBJIGhhdmUgbm8gaWRlYSBob3cgRUNEU0Egd29y a3Mgd2l0aCBTL01JTUUgZW5jcnlwdGlvbi4NCj4gPiA+DQo+ID4gPiBEb2VzIGFueW9uZSBoYXZl IGEgc3VnZ2VzdGlvbiBoZXJlPyAgSXMgYW55b25lIG9uIHRoaXMgbGlzdCB1c2luZw0KPiA+ID4g ZWl0aGVyIEVDRFNBIG9yIEVERFNBIHdpdGggZS1tYWlsPw0KPiA+ID4NCj4gPiA+IC0tLS0tc25p cC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4NCj4g PiA+IEkgZG9uJ3QgaGF2ZSBvbmUgKGFuZCBJIG1heSBuZXZlciBpZiBJIHJldGlyZSBiZWZvcmUg VVMgRE9EIG1vdmVzDQo+ID4gPiBvZmYgb2YNCj4gPiA+IFJTQTIwNDgpIGJ1dCBhbiBFQ0RTQSBj ZXJ0IHdvdWxkIGJlIHVzZWQgZm9yIGRpZ2l0YWwgc2lnbmF0dXJlIGluDQo+IFMvTUlNRS4NCj4g PiA+IEVuY3J5cHRpb24gd291bGQgdXNlIGEgc2VwYXJhdGUga2V5L2NlcnQgLSBub3QgRUNEU0Es IG1vc3QgbGlrZWx5DQo+ID4gPiBFQ0RIIHdpdGggYSBzZW1pLXN0YXRpYyBzY2hlbWUgKHNlbmRl ciBpcyBlcGhlbWVyYWwsIHJlY2lwaWVudCBpcyBzdGF0aWMpLg0KPiA+ID4NCj4gPg0KPiA+IEkn dmUgY3JlYXRlZCBhbiBFQ0RTQSBjZXJ0aWZpY2F0ZSB1c2luZyBPcGVuU1NMIGFuZCB1c2VkIHRo YXQgc3VjY2Vzc2Z1bGx5DQo+IHRvIGVuY3J5cHQgYW4gU01JTUUgbWVzc2FnZS4gT3BlblNTTCBz aW1wbHkgdXNlcyB0aGUgRUNEU0Ega2V5IGZvcg0KPiBFQ0RILiBJJ3ZlIGFsc28gY3JlYXRlZCBh IHByb3RvdHlwZSBpbiBDIyB0byB0aGUgc2FtZSB0aGluZyBhbmQgd2FzIGFibGUgdG8NCj4gZGVj cnlwdCB0aGUgbWVzc2FnZSBjcmVhdGVkIGJ5IE9wZW5TU0wuDQo+ID4NCj4gPiBTbyBjcmVhdGlu ZyBzYW1wbGUgY2VydGlmaWNhdGVzIGlzIHJlbGF0aXZlbHkgc3RyYWlnaHQgZm9yd2FyZDoNCj4g Pg0KPiA+IEdlbmVyYXRlIGtleToNCj4gPiBlY3BhcmFtIC1vdXQgZWNkc2Eua2V5IC1uYW1lIHNl Y3AyNTZyMSAtZ2Vua2V5DQo+ID4NCj4gPiBUaGUga2V5IGNhbiB0aGVuIGJlIHVzZWQgdG8gY3Jl YXRlIGEgY2VydGlmaWNhdGUgc2lnbmluZyByZXF1ZXN0IGFuZCB0aGUNCj4gYWN0dWFsIGNlcnQu DQo+ID4NCj4gPiBUaGUgZW5jcnlwdGlvbiBpbmRlZWQgdXNlcyBhbiBlcGhlbWVyYWwga2V5IGZv ciB0aGUgc2VuZGVyIGFuZCB0aGUgc3RhdGljDQo+IHB1YmxpYyBrZXkgZnJvbSB0aGUgcmVjaXBp ZW50cyBjZXJ0aWZpY2F0ZS4NCj4gPg0KPiA+IEBEZWIgQ29vbGV5LCB3aHkgZG8geW91IHNheSB5 b3Ugd291bGQgYSBkaWZmZXJlbnQgY2VydGlmaWNhdGU/DQo+IA0KPiBTZWN0aW9uIDUuMiBvZiBO SVNUIFNQIDgwMC01Ny0xIHJldiA1IGZvcmJpZHMgdXNpbmcgYSBrZXkgZm9yIGJvdGggc2lnbmlu ZyBhbmQNCj4gZW5jcnlwdGlvbiBhbmQgZ2l2ZXMgc2V2ZXJhbCByZWFzb25zLg0KPiANCj4gUkZD IDU0ODAgZG9lcyBhbGxvdyAiYW55IGNvbWJpbmF0aW9uIiBvZiB0aGUga2V5IHVzYWdlIGJpdHMg ZGlnaXRhbFNpZ25hdHVyZSwNCj4gbm9uUmVwdWRpYXRpb24gYW5kIGtleUFncmVlbWVudC4gSG93 ZXZlciwgbm90ZSB0aGF0IFJGQyA4ODEzIGRpc2FsbG93cw0KPiBrZXlFbmNpcGhlcm1lbnQgb3Ig ZGF0YUVuY2lwaGVybWVudCBpbiBnZW5lcmFsIEVDQyBjZXJ0aWZpY2F0ZXMgKGkuZS4gd2l0aA0K PiBhbGdvcml0aG0gaWRlbnRpZmllciBpZC1lY1B1YmxpY0tleSkuDQo+IA0KPiBKb25hdGhhbg0K DQo= From nobody Mon Nov 16 09:44:20 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C853A1338 for ; Mon, 16 Nov 2020 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 FmL2WXhO1TPB for ; Mon, 16 Nov 2020 09:44:17 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 48C553A1331 for ; Mon, 16 Nov 2020 09:44:17 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id r7so17623831qkf.3 for ; Mon, 16 Nov 2020 09:44:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Y7dAk+/eU0C6OV3KFX7LaLOjsImzlkaEMJC/yndfHMQ=; b=XZqglritpp33gpZKHtuyC/3/GKtdz0FHs8xX2XprSh7H//k3ebgGdXlD14dBC8jmzW NRGt5bk22Q6iD27QGr4CrACoEhNH8b5jFrsofbF+G4RoLqtOSg7qElT8DBavs+lZRdZD o6RvaSjoLvm0krUwPAzEbOxJPA1M1kuETajRHksan/NolC0qOjNCYU2zHFM5sioy5tVw 8+ep6Y4oh1AMlRK/OebnbXqNFzzmN5mGkEl2o11f1A2RfW+P2IKSTFx7smn6VuTf/R1u MW0BjWKOXsaj/nrbchECXdjBhxkB4rHjAvAUCI13W+QtSN+/StT6kaLK/GkgZapLFjOe hWKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Y7dAk+/eU0C6OV3KFX7LaLOjsImzlkaEMJC/yndfHMQ=; b=PQqhpaATCBUvMuidkaZVQ9o+GsPcfHg+Zf6yqjlefyUhAfIsEPnhArXXrMayODc1tB DjD+Su4RP+7N3VJPlWRpHwsi84+xcju1v4ESP5AbbRUzlR4wGg5SBG8QFNunR6TX5RFB u/PgC7qtJ5FgyHIeYuMAugrwAtLUNsltO06bmWSDp5VmhMRFtmLyhXWo1B6Mr86ohdxn JfGhctgNanKG0qNXP7105LqqLYQJlXayqZYNLoP0Ar27oSogg78Hp+ptNcXqYHPA6nnl lCO60URKi7r8JTtRlKaib2pgBjNw+3x2oAP5rMSFj1mfZc85yEQIA5XKCMD+R2weNI+q 5aiA== X-Gm-Message-State: AOAM531CFikbTSCn9gTSM2Czk89qWMLlo9xsWbZrsLVx8y2A7xb5aRdR J9IxfoN+ItCr1I20U5Jqf54YjGr+KFQ= X-Google-Smtp-Source: ABdhPJy+JJxsImZRKLSNK5ixH7i4Uakn3/nva1MkBWBKng0rK8nExN26PV5yY5ttgp1t5mudbHnTMQ== X-Received: by 2002:a37:7cd:: with SMTP id 196mr16146549qkh.246.1605548651109; Mon, 16 Nov 2020 09:44:11 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id v32sm2433937qtb.42.2020.11.16.09.44.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 09:44:10 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS WG'" References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: Date: Mon, 16 Nov 2020 12:44:09 -0500 Message-ID: <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMGb7PLGIUkstBph5ynWWmikEzkwGcA6vJAUgCblYA8vKfOwG3tgbYAqF2tfQDFQgJDgI0H83XAoeDFRKo4ESnoA== Content-Language: en-us Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 17:44:19 -0000 Below is the logic S/MIME Encrypting client should use to determine if a EC public key in a X.509 certificate can be used to create a recipient token. All of the following conditions should be met: 1. The algorithm OID in SPKI is EC Public Key or EC DH; and 2. If key usage is present, it sets key agreement bit; and 3. If EKU is present, it contain e-mail protection OID. On 2, an argument can be made that if algorithm OID is EC Public Key and key usage is absent, the key should not be used. Hopefully producers (i.e., CAs) always put key usage in general or when SPKI is EC public key. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Henning Krause Sent: Monday, November 16, 2020 12:24 PM To: Jonathan Hammell Cc: LAMPS WG ; Cooley, Dorothy E ; Deb Cooley ; Michael Richardson Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? Hi Jonathan, indeed NIST says we must not use the same keys, but the RFCs are not that clear: RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC certificates certificates (i.e. with algorithm identifier id-ecPublicKey, but also with id-ecDH or id-ecMQV). But the encryption with ECC uses ECDH, and per RFC 5280, ECDH should fall under the keyAgreement usage, or am I wrong? I can't find anything in those RFC that would forbid me to use the same certificate for signature and encryption. Did I overlook something? Kind regards, Henning > -----Original Message----- > From: Jonathan Hammell [mailto:jfhamme.cccs@gmail.com] > Sent: Montag, 16. November 2020 10:12 > To: Henning Krause > Cc: Deb Cooley ; LAMPS WG ; > Cooley, Dorothy E ; Michael Richardson > > Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? > > On Sun, Nov 15, 2020 at 12:50 PM Henning Krause > wrote: > > > > > -------snip-------------------------------------------------- > > > > > > > I have no idea how ECDSA works with S/MIME encryption. > > > > > > Does anyone have a suggestion here? Is anyone on this list using > > > either ECDSA or EDDSA with e-mail? > > > > > > -----snip--------------------------------------------- > > > > > > I don't have one (and I may never if I retire before US DOD moves > > > off of > > > RSA2048) but an ECDSA cert would be used for digital signature in > S/MIME. > > > Encryption would use a separate key/cert - not ECDSA, most likely > > > ECDH with a semi-static scheme (sender is ephemeral, recipient is static). > > > > > > > I've created an ECDSA certificate using OpenSSL and used that > > successfully > to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for > ECDH. I've also created a prototype in C# to the same thing and was > able to decrypt the message created by OpenSSL. > > > > So creating sample certificates is relatively straight forward: > > > > Generate key: > > ecparam -out ecdsa.key -name secp256r1 -genkey > > > > The key can then be used to create a certificate signing request and > > the > actual cert. > > > > The encryption indeed uses an ephemeral key for the sender and the > > static > public key from the recipients certificate. > > > > @Deb Cooley, why do you say you would a different certificate? > > Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both > signing and encryption and gives several reasons. > > RFC 5480 does allow "any combination" of the key usage bits > digitalSignature, nonRepudiation and keyAgreement. However, note that > RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC > certificates (i.e. with algorithm identifier id-ecPublicKey). > > Jonathan _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 16 12:27:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ABA3A1422 for ; Mon, 16 Nov 2020 12:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=xUPIEV6N; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=1gSI5ML/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klcMebELYuST for ; Mon, 16 Nov 2020 12:27:16 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2B63A1413 for ; Mon, 16 Nov 2020 12:27:16 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605558435; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CG0uzD71kaFrfW0qJLU7tmYP9lQfpH2wkk+CgP9Y2EE=; b=xUPIEV6NLq7gOz+XOnapnuKey3IRRxTGnV6ZRi/Vf0ZnNHb3aiNuMr0oCBNQUEL6bjszX SKxzKZhXR0UWhzHCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605558435; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=CG0uzD71kaFrfW0qJLU7tmYP9lQfpH2wkk+CgP9Y2EE=; b=1gSI5ML/r6VdpV+x0lIchYw9G3zAERMUTjc+0zOCpDnpPhYBomtmFZUcU/rHvZkCdOR67 +4JBfsHOaMEU938w9rrm0aE2jcHXEySLFsIvJgxbWZvTasLn+o0JDLnlGTYmqfG4E++Fzuc RKDUdO8xNQY1enffI5bGa3jifN+xnhStB1avqiYraOdznukDB8Gom+htKWSxyWoeH4VnEAM I25UqD5VNk/mBkcpd+BZspWWLIz+N1/meZFvcX83FnYkL0EtTX1IfBWtW+XFGM13RrRmSr2 OfYgLw+LkruRPFA/klkfsK7YLxoQcM8Y+ecdhWyG66TBnoKVP4c8FuSuzw5w== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 376D2F9A6; Mon, 16 Nov 2020 15:27:15 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1773E20316; Mon, 16 Nov 2020 15:19:24 -0500 (EST) From: Daniel Kahn Gillmor To: Santosh Chokhani , 'LAMPS WG' In-Reply-To: <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 16 Nov 2020 15:19:23 -0500 Message-ID: <873619dph0.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 20:27:25 -0000 --=-=-= Content-Type: text/plain On Mon 2020-11-16 12:44:09 -0500, Santosh Chokhani wrote: > Below is the logic S/MIME Encrypting client should use to determine if a EC > public key in a X.509 certificate can be used to create a recipient token. > > All of the following conditions should be met: > > 1. The algorithm OID in SPKI is EC Public Key or EC DH; and > > 2. If key usage is present, it sets key agreement bit; and > > 3. If EKU is present, it contain e-mail protection OID. > > On 2, an argument can be made that if algorithm OID is EC Public Key and key > usage is absent, the key should not be used. Hopefully producers (i.e., > CAs) always put key usage in general or when SPKI is EC public key. Thanks for this! This seems like a useful bit of guidance to include in draft-dkg-lamps-e2e-mail-guidance. I've added some approximation of it in git in the "Peer Certificate Selection" section, over at: https://gitlab.com/dkg/e2e-mail-guidance.git -- i've included the text below. Could you take a look and suggest edits if something could be improved? -------- #### Peer Certificate Selection {#peer-cert-selection} When composing an encrypted message, the MUA needs to select a certificate for each recipient that is capable of encryption. To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that *all* of the conditions below are met: - The certificate must be valid, not expired or revoked. - It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address. - The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption. Examples include (TODO: need OIDs) - RSA - EC Public Key - EC DH - If keyUsage is present, the key agreement bit must be set - If extendedKeyUsage is present, the e-mail protection OID must be present. TODO: If OID is EC Public Key and keyUsage is absent, what should happen? TODO: what if multiple certificates meet all of these criteria for a given recipient? -------- Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7LeywAKCRDEDyVUMvKB D1rHAQDqKh5rYE1lky0Q8qYUvqcS+nrYPNujQhikviJc4TQlgAEAlY4+14dfTYCL 00CshOwAZWFRGfuJvqmSVHDWdjMA0gI= =sHn6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 12:50:43 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454C3A1412 for ; Mon, 16 Nov 2020 12:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 YJilwZxNa-De for ; Mon, 16 Nov 2020 12:50:41 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 29A4C3A140D for ; Mon, 16 Nov 2020 12:50:41 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id n132so18358360qke.1 for ; Mon, 16 Nov 2020 12:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=SK7JUKJNJYmWvdACKnu3UfNmD+4dPRyvlxiWx6dbHSk=; b=iq20fSG01Bv9SkaHL+OKuC8S2+S8/W8G31w1Uaq1RVzRoAvEscRcLfLqNUbhhuwQ/y Gq8w5xRnVfzWkbSZYUDd2pgUqZeWS8HbDFzAaSJH/KeByMf5AbKnWXcrteJDk33o+8Bo QtsVlsm6gmp0FfRwK9TfVrPVLqF3MOMc9YlXIsnh5Z4btvmhfCfk7sjkD7/Sjj+mggpz 9oOg5nrvm4F1b8ABb3HAxigB0UGPguv2bOKU3WRfmBKROtdsAymjiEsAxZ9x+rcsxEXV R78/7lP/8RQoV0d4eMVfiKeCjyKJUcHj92wSHbNutXeFH6y3zT9Ps2QtBzO1l8brKQ8D hDjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=SK7JUKJNJYmWvdACKnu3UfNmD+4dPRyvlxiWx6dbHSk=; b=Mp14CgWHGkpeg55uVSjcyMZtZhFu2VhZRUryEp9XyfnBP/9/Wckzb8f0LUcYptpe7A SnD+TurOjoSxVfgNQck1hRbXQTRahRP/QCV2q8fMyD8rFgp/k2m++VfTC4A8sTysUK93 FayD3D5F/GDC6nEpy9xBYrgYbDBmcYpWt6eFK4nBGpYjtWCznNvdvm3Mp1EPTSSmP6Rj eUzedA46ZEa1s3Di27FmEi2SGBMZqMjUfWZTkrNK5uSNqZF2eWHoLYBorBUe+tpuH30m PBZMVHEXsedZM9vABT3iXemhis6K/JxM3BjU4OKD3D5ifOQLSBPMdWpalYOUj2QI+OYq oSAQ== X-Gm-Message-State: AOAM5306A+0UgmDhTAbMYhbl5pRO4N6KqVRP3DJF/JUf9U0hSQsUU51p ecuiIBc+kA0x7AGP2clzT3Q5Dkk/weQ= X-Google-Smtp-Source: ABdhPJwncge9oqH51UMw4TMHBktkRtQKJ9HYu60bcAWGe+zlLIxiqFbDPMR9Nn+ZVtD5u0qu9csqiw== X-Received: by 2002:a37:7685:: with SMTP id r127mr15731354qkc.261.1605559839710; Mon, 16 Nov 2020 12:50:39 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id x5sm13489582qtx.61.2020.11.16.12.50.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2020 12:50:38 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS WG'" References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> In-Reply-To: <873619dph0.fsf@fifthhorseman.net> Date: Mon, 16 Nov 2020 15:50:37 -0500 Message-ID: <0d0401d6bc5a$23733680$6a59a380$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMGb7PLGIUkstBph5ynWWmikEzkwGcA6vJAUgCblYA8vKfOwG3tgbYAqF2tfQDFQgJDgI0H83XAoeDFRICV3NuxAGzC2AwqMAlmHA= Content-Language: en-us Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 20:50:42 -0000 DKG, Thanks. I would revise item 3 to permit anyExtendedKeyUsage and thus item 3 would read as follows: 3. If EKU is present, it contains at least one of the following OIDs: e-mail protection, anyExtendedKeyUsage. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net] Sent: Monday, November 16, 2020 3:19 PM To: Santosh Chokhani ; 'LAMPS WG' Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? On Mon 2020-11-16 12:44:09 -0500, Santosh Chokhani wrote: > Below is the logic S/MIME Encrypting client should use to determine if > a EC public key in a X.509 certificate can be used to create a recipient token. > > All of the following conditions should be met: > > 1. The algorithm OID in SPKI is EC Public Key or EC DH; and > > 2. If key usage is present, it sets key agreement bit; and > > 3. If EKU is present, it contain e-mail protection OID. > > On 2, an argument can be made that if algorithm OID is EC Public Key > and key usage is absent, the key should not be used. Hopefully > producers (i.e., > CAs) always put key usage in general or when SPKI is EC public key. Thanks for this! This seems like a useful bit of guidance to include in draft-dkg-lamps-e2e-mail-guidance. I've added some approximation of it in git in the "Peer Certificate Selection" section, over at: https://gitlab.com/dkg/e2e-mail-guidance.git -- i've included the text below. Could you take a look and suggest edits if something could be improved? -------- #### Peer Certificate Selection {#peer-cert-selection} When composing an encrypted message, the MUA needs to select a certificate for each recipient that is capable of encryption. To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that *all* of the conditions below are met: - The certificate must be valid, not expired or revoked. - It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address. - The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption. Examples include (TODO: need OIDs) - RSA - EC Public Key - EC DH - If keyUsage is present, the key agreement bit must be set - If extendedKeyUsage is present, the e-mail protection OID must be present. TODO: If OID is EC Public Key and keyUsage is absent, what should happen? TODO: what if multiple certificates meet all of these criteria for a given recipient? -------- Regards, --dkg From nobody Mon Nov 16 17:38:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337F73A0D20 for ; Mon, 16 Nov 2020 17:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=SO5tpAT5; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=b//EEGpO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shO2Ao7XTNW3 for ; Mon, 16 Nov 2020 17:38:28 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972163A0D09 for ; Mon, 16 Nov 2020 17:38:28 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605577107; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=/HQNBhX+Gt1FrgFwRkJlaVO3qV6i2WEY/9C9hT8lnI8=; b=SO5tpAT5wsmspoEhaAKFPuIVm/b1AlDpatZbmq4kZiqKz8n54NkS0KQ59rPq2a3MXwUSe sxlWZFaOd2KHiB/DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605577107; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=/HQNBhX+Gt1FrgFwRkJlaVO3qV6i2WEY/9C9hT8lnI8=; b=b//EEGpOe1gbP9Qxeim9qnn/EuHxAfHARpFSgzy0GZhPDIHk0lfgI//S95EdbwjSrzAgo 7+QxubraUmwsbatTeFKsOkmOQHR5a9lJ0Vf9WpiUSUYad7Q9kOQOijPEDi9kuRbt2FZSVS9 nxsRKX+RsqjomdGzE7qZrBDBjRTU3N9zossJOwPmHh1LSPtD6ftN5PLgAOpZcNTxHs08xzV z1a9Fi2g/G2nSAG3dT/ZD1Hke/PkddA/HqVPOfbUyuSFNzyGn3xLvf5MbcoZ4A8VIn9qJIX OJb6phe4f7k0/jOwV4psUeZ0eKUhlyMQQ6bhYjSfRTb/ci/L44ZsUzlxGZCw== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 457E2F9A5; Mon, 16 Nov 2020 20:38:27 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 6B4C120338; Mon, 16 Nov 2020 16:07:07 -0500 (EST) From: Daniel Kahn Gillmor To: Santosh Chokhani , 'LAMPS WG' In-Reply-To: <0d0401d6bc5a$23733680$6a59a380$@gmail.com> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> <0d0401d6bc5a$23733680$6a59a380$@gmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Mon, 16 Nov 2020 16:07:06 -0500 Message-ID: <87sg99c8p1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 01:38:30 -0000 --=-=-= Content-Type: text/plain On Mon 2020-11-16 15:50:37 -0500, Santosh Chokhani wrote: > I would revise item 3 to permit anyExtendedKeyUsage and thus item 3 would > read as follows: > > 3. If EKU is present, it contains at least one of the following OIDs: e-mail > protection, anyExtendedKeyUsage. Thanks, revised in Git. I've added you and Deb to the Acknowledgements section. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7Lp+wAKCRDEDyVUMvKB D4bWAQDxAta41g74yH7NVxlPTHVNNPlmHKUMEJggf9VXD8hu/wEA7Cul6MBmDyng 2yQjJjyU4r2CXJN+WjyO4zp4L/EPcQc= =iVwl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 16 23:08:33 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277423A10E7 for ; Mon, 16 Nov 2020 23:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nn-EiinFhtvR for ; Mon, 16 Nov 2020 23:08:30 -0800 (PST) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 C9F4D3A10E6 for ; Mon, 16 Nov 2020 23:08:30 -0800 (PST) Received: by mail-oo1-xc36.google.com with SMTP id t142so4499104oot.7 for ; Mon, 16 Nov 2020 23:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GHT5b34l3R/tdIltyIrVU5KQq+G2dxX1GD7mhARc+xM=; b=euQG7hRcYuYps6vFmya3sX83x4tGAzZGonTgD4b4LPCm6rpXVX1bWnH7qfRuA9qQdp 6diD5fZ6rA4FrFcy1fbwJf/gHzNi2XEeoJawbYcGURzBkwgJAr850n+GFe0jgatPsuRs bNtAFtwRweK0ZzSO5SRIFQXgxbfxYJjCRl9C7MaCPhiTPyAFTcXCUpNgPJmDSJrMtCMZ +Atf79evW8TgdWOnVVUa1RLVXoDIj43cwPD9mt6AkATThaVFUq8UA8F/bXx8CGSi+pQ1 P/49qNnpJ/piGp6xlPLB22dsP0GYgYNryFkAKX32xGrf5mHAgC4Iz/e1T8boYdlNwWqC FB5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GHT5b34l3R/tdIltyIrVU5KQq+G2dxX1GD7mhARc+xM=; b=VfmnfpNx7GwUxSWQeOLJu6yCha9wdBoJjF54bwkGj3s1QL6nTz/NFzuWUNzbhg8sc6 aPJUppemSgjvP2G3ceummWDJ1JuNpZlqAuxmJvTcE0aTyqmP9vJngas88fpBDSXW4eoD GEFp6cK0ObKeOB3VNP7xE2hJDypix3ZD+Gm3NmjQFs6oRgfK49Mvs+xKIssTTVTU7Yob Bof4dfB+MV/bZ73u593gB/pSYG46ASbGum5qGYPU6mE1CA9Ok+SbjeoBgHeIW5N8yd2Q YcSMjzVPpuPfq1+AZTjrybog2wBy6ONRZ3eLKHvTxpz+WB7hdc7H3GFX80ayCdGuEJPT 4DwQ== X-Gm-Message-State: AOAM530wkoS7iezEQzJVCLr0JMow513rILzpHQGqlUZX2UQ36UihR+6f wV9NfUl2DZgicuIW0eIz5tAh8P5A5brDmXIdyRs= X-Google-Smtp-Source: ABdhPJwd0G6CeiVN7KlHIKrE7Piowf7uw207rkl+SA2pHCfsRt7awMC/WkcFE5rmc7WFwD8/OMWD7eNkFBdilTz3X1Q= X-Received: by 2002:a4a:d1a7:: with SMTP id z7mr2128110oor.92.1605596910005; Mon, 16 Nov 2020 23:08:30 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> In-Reply-To: <873619dph0.fsf@fifthhorseman.net> From: Jonathan Hammell Date: Tue, 17 Nov 2020 02:08:19 -0500 Message-ID: To: Daniel Kahn Gillmor Cc: Santosh Chokhani , LAMPS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 07:08:32 -0000 DKG, Small correction to your Peer Certificate Selection text below. On Mon, Nov 16, 2020 at 3:27 PM Daniel Kahn Gillmor wrote: > To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that *all* of the conditions below are met: > > - The certificate must be valid, not expired or revoked. > - It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address. > - The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption. > Examples include (TODO: need OIDs) > - RSA > - EC Public Key > - EC DH > - If keyUsage is present, the key agreement bit must be set > - If extendedKeyUsage is present, the e-mail protection OID must be present. The criteria "If keyUsage is present, the key agreement bit must be set" only applies to EC Public Key and ECDH. In the case of an RSA certificate, the keyUsage should have the key encipherment bit set instead (since it is used to encrypt the content encryption key). Jonathan From nobody Tue Nov 17 00:25:14 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0215B3A07F9 for ; Tue, 17 Nov 2020 00:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTvnejQWffPe for ; Tue, 17 Nov 2020 00:25:11 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6113A07E6 for ; Tue, 17 Nov 2020 00:25:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6C64E300B8A for ; Tue, 17 Nov 2020 03:25:08 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s3VlDaTfAeZr for ; Tue, 17 Nov 2020 03:25:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0BE94300435 for ; Tue, 17 Nov 2020 03:25:06 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_0D5D609E-6EE1-45B0-82B4-C37113E2B431" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 17 Nov 2020 03:25:08 -0500 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> To: LAMPS In-Reply-To: <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 08:25:13 -0000 --Apple-Mail=_0D5D609E-6EE1-45B0-82B4-C37113E2B431 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Remember that this is part of the LAMPS WG charter: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. Russ > On Nov 12, 2020, at 10:24 AM, Russ Housley = wrote: >=20 > Erik: >=20 > X.509 defines the id-ce-noRevAvail extension. It was first referenced = by RFC 3281 for use in attribute certificates, >=20 >> name id-ce-noRevAvail >> OID { id-ce 56 } >> syntax NULL (i.e. '0500'H is the DER encoding) >> criticality MUST be FALSE >=20 >=20 > X.509 says: This extension shall not be included in public-key = certificates or in attribute certificates issued to AAs.=20 >=20 > We do not seems to have an extension equivalent to id-ce-noRevAvail = for public-key certificates. >=20 > With the move toward short lived public-key certificates, especially = with the work in the IETF ACME WG, I wonder if X.509 can be changed to = allow this extension to appear in end-entity public-key certificates. >=20 > Russ >=20 --Apple-Mail=_0D5D609E-6EE1-45B0-82B4-C37113E2B431 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Remember that this is part of the LAMPS WG charter:

1. Specify the use of short-lived X.509 = certificates for which no
revocation information is made = available by the Certification Authority.
Short-lived = certificates have a lifespan that is shorter than the time
needed to detect, report, and distribute revocation = information. As a
result, revoking short-lived = certificates is unnecessary and pointless.

Russ

On Nov = 12, 2020, at 10:24 AM, Russ Housley <housley@vigilsec.com> wrote:

Erik:

X.509 defines the id-ce-noRevAvail extension.  It = was first referenced by RFC 3281 for use in attribute = certificates,

     name =           id-ce-noRevAva= il
     OID =            { = id-ce 56 }
     syntax =         NULL (i.e. '0500'H is = the DER encoding)
     criticality =    MUST be FALSE

X.509 = says:  This extension shall = not be included in public-key certificates or in attribute certificates = issued to AAs. 

We do not seems to have an extension = equivalent to id-ce-noRevAvail for public-key certificates.

With the move toward = short lived public-key certificates, especially with the work in the = IETF ACME WG, I wonder if X.509 can be changed to allow this extension = to appear in end-entity public-key certificates.

Russ


= --Apple-Mail=_0D5D609E-6EE1-45B0-82B4-C37113E2B431-- From nobody Tue Nov 17 01:08:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511C03A0A22 for ; Tue, 17 Nov 2020 01:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=qqT5svLa; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=1XRwHaTM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOTGrwoWlOTr for ; Tue, 17 Nov 2020 01:08:28 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FE23A0A1F for ; Tue, 17 Nov 2020 01:08:27 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605604106; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=mwu7AuWkKUdZYmsG1u0W8GTAZNuOW2V378OPxh/WXEQ=; b=qqT5svLaaBatuCZZKRPy2m0eXC70z+jP1d9t0+fm703uGKIIIQPPOoxyijl/mn02GSMk8 NbEwXBPL7dlSH4EDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605604106; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=mwu7AuWkKUdZYmsG1u0W8GTAZNuOW2V378OPxh/WXEQ=; b=1XRwHaTMQj97qhX5LYscoXQBLZKTTWjWgz/8NNPAZkkiassiypQ8e9zq8CvIUCJY03j7e 8rr2n3Pn7QSgJ0FsRfK5L0t8Yzos3aptitsqEpIIANlMfIogHlLZXQ9pdASMFK2cjg6Hvne yLmuRo+hiVBfCbiRuSwR3JdPItYx0JBdyt5UPrpaLrGDXalOpX/5sZ4BugL+nJ4287EPd1P kCJjrHCXd8m3Tp+q62j+OUv5yG4RBBJlVMI47yI4XyBZ8nhtQIWYM9e7dI7tq/5RhtARaSc 6qOnmS1ZDi1aD2sqGv7l8FZ8FSzgUPo7IxGuMa77cfy6ZcHwwyRS4qQ6riCQ== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 6E71DF9A5; Tue, 17 Nov 2020 04:08:26 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 26DFB20316; Tue, 17 Nov 2020 02:47:27 -0500 (EST) From: Daniel Kahn Gillmor To: Jonathan Hammell Cc: Santosh Chokhani , LAMPS WG In-Reply-To: References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 17 Nov 2020 02:47:26 -0500 Message-ID: <87blfwctm9.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 09:08:29 -0000 --=-=-= Content-Type: text/plain On Tue 2020-11-17 02:08:19 -0500, Jonathan Hammell wrote: > The criteria "If keyUsage is present, the key agreement bit must be > set" only applies to EC Public Key and ECDH. In the case of an RSA > certificate, the keyUsage should have the key encipherment bit set > instead (since it is used to encrypt the content encryption key). Thanks for the suggestion, Jonathan. I've updated it to the text below. Please keep the feedback coming! --dkg ----------- #### Peer Certificate Selection {#peer-cert-selection} When composing an encrypted message, the MUA needs to select a certificate for each recipient that is capable of encryption. To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that *all* of the conditions below are met: - The certificate must be valid, not expired or revoked. - It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address. - The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption. Examples include (TODO: need OIDs) - RSA, with keyUsage present and the "key encipherment" bit set - EC Public Key, with keyUsage present and the "key agreement" bit set - EC DH, with keyUsage present and the "key agreement" bit set - If extendedKeyUsage is present, it contains at least one of the following OIDs: e-mail protection, anyExtendedKeyUsage. TODO: If OID is EC Public Key and keyUsage is absent, what should happen? TODO: what if multiple certificates meet all of these criteria for a given recipient? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7OADgAKCRDEDyVUMvKB DwkyAQD9Y5k1xjAwj4dIWwb50ewGW3TJfC+SFPNVQtx5thPuQwD+LUWXAdzQZGWe wJk3hvwbAzDdAWuMFK8JuaxGoszEwAs= =gMhS -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 01:08:34 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4F3A0A1F for ; Tue, 17 Nov 2020 01:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HJucqp9AnWIl for ; Tue, 17 Nov 2020 01:08:27 -0800 (PST) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 8B04E3A09CC for ; Tue, 17 Nov 2020 01:08:27 -0800 (PST) Received: by mail-ot1-x32f.google.com with SMTP id k3so18680566otp.12 for ; Tue, 17 Nov 2020 01:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p3h8rS/2C5J6II4EI80cbj8He0Rfjk67LWKxmvd6vdI=; b=QzHeGb/oHNQKAmaVCx9ibDkh2yZW5Mow88vvFk0hk+IEKly0cPuQ11zKiiBonpco5r ziKYfL8eke+CUYzfHwkb9sdH/9QvvxfyPKs0nDNnUOGnlxi7Dz8iqs7vamGk3br3UQME QV2hCsWujZak0RikwjGYKv140/Xd9TvaB1ZJTwuGEccUKaK3vHQsxEmqSHHAhAGdO/1Q zoW605sVbMlwfjEBXCTehbo+9S3OAhS2yCXhL75kNfRaLFr4okgIDjg8LxA4PavPim6M Bf+9kOJu4N2MahH5EjMdbWVsGX4c7wcKN9UnH3qGsZbYwAgkcCceSVGNd8aoVCCFz7OX vAkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p3h8rS/2C5J6II4EI80cbj8He0Rfjk67LWKxmvd6vdI=; b=G2u1o2zeAfiz8nSo4nTliEuX3leMehfZ0PJZXYU0/oaHPupg/CptPCdFQhbHQsR2sQ sm2BDyLaSAkP1SVbNXqnZoFWQ03Bi3Yw8ZxvQfU9U+wFESd6sjaHMDGMpDfI5ZiSCoBL 3OH3iJXBIqEJqDzMLB9m7TprVPbLWjokj9vkBK3KfDOGTjYuvFURqLLl03J2Uptuwl3O g2kxRH4CEfkSMRdx5x3KVgbscQ4eGCCKy5U58tvZSVD/YUzla0vo/ePzKQN/wlZ10p0E uXrSCv71oMxkbAPvNsGJuQIMP6nWkHQ7VqtbyOr7/Bz9Ledvv2fSB30lZZekKJvmFQ5p jiGQ== X-Gm-Message-State: AOAM530XgK1asCwdLZ1RnLQfGgkpU+RSJ4ju4TxAnUTxU8XCrw92LWdq 87mAQSb7+WRsBo76F22qFv3GT/cIPufZEXi8iPXEvjs= X-Google-Smtp-Source: ABdhPJwnJ9eEi9XOtZqQHi4v4itH0IruP7gqPz2hIcDc8mGRugvfd3dXCrG3MzFVbV5xTFMNV6+SBtzg2NevXE/EvzI= X-Received: by 2002:a9d:5904:: with SMTP id t4mr628819oth.109.1605604106421; Tue, 17 Nov 2020 01:08:26 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> In-Reply-To: From: Deb Cooley Date: Tue, 17 Nov 2020 04:08:14 -0500 Message-ID: To: LAMPS WG Cc: Daniel Kahn Gillmor , Santosh Chokhani , Jonathan Hammell Content-Type: multipart/alternative; boundary="00000000000069ca9605b449d66a" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 09:08:30 -0000 --00000000000069ca9605b449d66a Content-Type: text/plain; charset="UTF-8" I would not include the anyExtendedKeyUsage EKU.... The pro/con of the anyEKU is that you can use the key/cert for anything. If that is what you desire - it is a 'pro'. If you wish to constrain the use of a key/cert, it is a 'con'. My current employer does not allow the anyEKU to be populated. We consider it to be a 'con'. YMMV Deb Cooley On Tue, Nov 17, 2020 at 2:08 AM Jonathan Hammell wrote: > DKG, > > Small correction to your Peer Certificate Selection text below. > > On Mon, Nov 16, 2020 at 3:27 PM Daniel Kahn Gillmor > wrote: > > To select such a certificate for a given destination e-mail address, the > MUA should look through all of its known certificates and verify that *all* > of the conditions below are met: > > > > - The certificate must be valid, not expired or revoked. > > - It must have a subjectAltName of type rFC822Name whose contents > exactly match the destination address. > > - The algorithm OID in the certificate's SPKI is known to the MUA and > capable of encryption. > > Examples include (TODO: need OIDs) > > - RSA > > - EC Public Key > > - EC DH > > - If keyUsage is present, the key agreement bit must be set > > - If extendedKeyUsage is present, the e-mail protection OID must be > present. > > The criteria "If keyUsage is present, the key agreement bit must be > set" only applies to EC Public Key and ECDH. In the case of an RSA > certificate, the keyUsage should have the key encipherment bit set > instead (since it is used to encrypt the content encryption key). > > Jonathan > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --00000000000069ca9605b449d66a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would not include the anyExtendedKeyUsage EKU....= =C2=A0 The pro/con of the anyEKU is that you can use the key/cert for anyth= ing.=C2=A0 If that is what you desire - it is a 'pro'.=C2=A0 If you= wish to constrain the use of a key/cert, it is a 'con'.=C2=A0
=

My current employer does not allow the anyEKU to = be populated.=C2=A0 We consider it to be a 'con'.=C2=A0 YMMV
<= div>
Deb Cooley

On Tue, Nov 17, 2020 at 2:08 AM Jona= than Hammell <jfhamme.cccs@gma= il.com> wrote:
DKG,

Small correction to your Peer Certificate Selection text below.

On Mon, Nov 16, 2020 at 3:27 PM Daniel Kahn Gillmor
<dkg@fifthhor= seman.net> wrote:
> To select such a certificate for a given destination e-mail address, t= he MUA should look through all of its known certificates and verify that *a= ll* of the conditions below are met:
>
> - The certificate must be valid, not expired or revoked.
> - It must have a subjectAltName of type rFC822Name whose contents exac= tly match the destination address.
> - The algorithm OID in the certificate's SPKI is known to the MUA = and capable of encryption.
>=C2=A0 =C2=A0Examples include (TODO: need OIDs)
>=C2=A0 =C2=A0- RSA
>=C2=A0 =C2=A0- EC Public Key
>=C2=A0 =C2=A0- EC DH
> - If keyUsage is present, the key agreement bit must be set
> - If extendedKeyUsage is present, the e-mail protection OID must be pr= esent.

The criteria "If keyUsage is present, the key agreement bit must be set" only applies to EC Public Key and ECDH.=C2=A0 In the case of an R= SA
certificate, the keyUsage should have the key encipherment bit set
instead (since it is used to encrypt the content encryption key).

Jonathan

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--00000000000069ca9605b449d66a-- From nobody Tue Nov 17 03:47:12 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777823A1319 for ; Tue, 17 Nov 2020 03:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=/RAWVIlz; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=ONRTCp0V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxjPMGgu3rcU for ; Tue, 17 Nov 2020 03:47:05 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3CD3A11E4 for ; Tue, 17 Nov 2020 03:46:55 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605613613; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dIpqz7dzkNXS+Pn87ROdoVw0gesYaMjSVO5v93aW8Yw=; b=/RAWVIlzHFI0Ki/tjKbYisgH3ZHnQJHRMZaV3UgFmgf9QoIQ+jysNDkJ1B0BT8vgxl9GP /pF8/vSrThpHsCRBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605613613; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=dIpqz7dzkNXS+Pn87ROdoVw0gesYaMjSVO5v93aW8Yw=; b=ONRTCp0VH7fSlAQAyq7zm7+NKBdDtiO2kiqkG3j1N9ieLhcj8Ol5GWYPjx00SyRJdQymu /uEA+v7OcYpKfMT0vAutCFfkBPPCMCUzStCbI2H9eM5FnbVXUYb5wz4i5TTquaS6a36xlnf BD/fwPRtkJKtN4CIVJkv8wwu9dnJSI949cIcIRZheU0aBzj46g4OaU48OxJi5dPQwnMZpuy I9ukNtfTk0megmFFlZ9+W0tAOUE2CJ/BU1gVTBV/stDslQE3n9YufqsaNlRCQkRWfKBGQCl ARP/ZjUPIK+uag7LkNHxkt79CTyUShwTdzi/8OGnUaPPOkmlpYRIVPGKXM4w== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CA80FF9A5; Tue, 17 Nov 2020 06:46:52 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0207420316; Tue, 17 Nov 2020 06:40:24 -0500 (EST) From: Daniel Kahn Gillmor To: Alexey Melnikov , LAMPS WG In-Reply-To: <878sb7gss6.fsf@fifthhorseman.net> References: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> <878sb7gss6.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 17 Nov 2020 06:40:24 -0500 Message-ID: <878sb0citz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] Proposal to adopt "Guidance on End-to-End E-mail Security" (draft-dkg-lamps-e2e-mail-guidance-00) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 11:47:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2020-11-11 22:26:01 -0500, Daniel Kahn Gillmor wrote: > On Tue 2020-11-10 18:20:43 +0000, Alexey Melnikov wrote: > >> I would like to propose that this document >> [draft-dkg-lamps-e2e-mail-guidance] to be adopted by LAMPS. It will be >> a dependency for the Header Protection draft and I think 2 drafts have >> complementary scopes. [=E2=80=A6] > As the initial author of the draft, i'd be happy to have it put under > the aegis of the WG, and i think it's definitely relevant here. I also > volunteer to be the editor of it if it's adopted, and am willing to > shape it according to the consensus of the WG. in the WG meeting today at IETF 109, Russ suggested that we might need some additional text in the charter to be able to adopt this draft. I'm proposing the following addition: 4. Provide concrete guidance for implementers of mail user agents to promote interoperability of end-to-end cryptographic protection of e-mail messages. This may include guidance about the generation, interpretation, and handling of protected messages; management of the relevant certificates; documentation of how to avoid common failure modes; strategies for deployment in a mixed environment; and test vectors and examples that can be used by implementers and interop test suites. A more robust consensus among mail user agent implementers should result in more usable and useful cryptographic security guarantees for users of the tools. Note that this ought to be sufficient to cover both the e2e-mail-guidance document discussed in this thread, and also draft-dkg-lamps-samples discussed in this list over the last week, if that one wasn't already covered (some folks seem to think the lamps-samples draft is already at last implicitly covered by the current chartrer; this would just ensure that it's explicit). If anyone has any concerns, or suggested edits to this charter addition, i'd be happy to see them. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7O2qAAKCRDEDyVUMvKB D+8FAP499BvifehfUy5zOybeuoccHNdgaqPvRx5nXCrYMePWRAEA/0bTv7xIG0rV Txu9wr/9oE4r2+WwmPSQKNv4e69Jagg= =aWet -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 03:47:14 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF63A131B for ; Tue, 17 Nov 2020 03:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=6Q/3Xr5q; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Wqqqa+to Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz03GrS67oFu for ; Tue, 17 Nov 2020 03:47:05 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA593A11CA for ; Tue, 17 Nov 2020 03:46:55 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605613613; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OSPCFfRzwaqtGJYhq0HGXikZxAFVe3Ih6P9CIX8oLVk=; b=6Q/3Xr5qbgnXYm91Ms28Y/MJZhxe7CG2VJXbhRiTe4QN2Eo+CD+QVPU3c4qGhHiMA6M8t 5GS8o/HrgBmF6mGDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605613613; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OSPCFfRzwaqtGJYhq0HGXikZxAFVe3Ih6P9CIX8oLVk=; b=Wqqqa+to5i0V7bVq8tOCAqYW8j4+lBV0jyX6HuDLBseUA4Wcz2Zd7HgVkClr273X6jPHc u7WD1Mq46uf97y3fRr9xetPNnP+bLULfWHeAbd1jeSRPBe+eoa3OSFyUv42tBUGN8MgdJas 4m/wQfS3fWb21ZCUsW4Mvb4lAxm2UAF2b/htGZmJ9UoYGE+N91/IvNH8APRSPp80tC8c/IX Y3X5wN42tp0QWLM7F6c3+qvDACYbBuU9N+nf2hgcBRUqMHW/ppyVCzMd60Vvr5Y1Byluz/3 WuIx/0VWIzff63pea1d497eEECQsNy6Etj/MW98iHHWnPB/sCe8PRH9+CpZg== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D4728F9A6 for ; Tue, 17 Nov 2020 06:46:52 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1870E2046B; Tue, 17 Nov 2020 06:46:04 -0500 (EST) From: Daniel Kahn Gillmor To: LAMPS WG In-Reply-To: <87361pjjtu.fsf@fifthhorseman.net> References: <87361pjjtu.fsf@fifthhorseman.net> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 17 Nov 2020 06:46:03 -0500 Message-ID: <874klocikk.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 11:47:11 -0000 --=-=-= Content-Type: text/plain On Wed 2020-11-04 09:08:29 -0500, Daniel Kahn Gillmor wrote: > So, I'm asking for WG adoption of this document. If the chairs think > we'd need a charter revision to adopt it, I propose adding the following > paragraph to the charter: > > 4. Publication of sample keys and certificates for use with > S/MIME. Having stable, well-known keys and certificates for use > in generating test vectors will facilitate testing and > interoperability among S/MIME-enabled e-mail implementations. I'm withdrawing this proposed charter amendment in favor of the amendment proposed in Message-ID: 878sb0citz.fsf@fifthhorseman.net, which covers both draft-dkg-lamps-samples and draft-dkg-lamps-e2e-mail-guidance. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7O3+wAKCRDEDyVUMvKB DwwvAQCUvDGDNsrfXclRYm96NUGUbIRM6MtUsaKcaEJSrliibgD/Z3PlNXwwJobb h8cSdWCTc+ZhI9mSHVLl5cGmW+8DRAI= =mgtR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 05:10:09 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD533A1018 for ; Tue, 17 Nov 2020 05:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXBEuTst4JbN for ; Tue, 17 Nov 2020 05:10:07 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD203A0F9D for ; Tue, 17 Nov 2020 05:10:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605618605; d=isode.com; s=june2016; i=@isode.com; bh=yge4hzL6VpAB86I87z8sfUBSffotQno4GpTPt8UFGEU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qMi2mUyBC9KRy45ZWxu/iyVdQoBLu00Z3UoC0jPMjlLFthXCx+N/n/mqg9RE68+9zOdN4Y pEOtSoh7X+Ug2Vfi40BTerr/u0sbIW+4vkGIOkzLVvUF5y6a/eKnF0R2uLAsFNtK1aaRHO FxA8pvPoGAgLNAylbvbA3sSdXyDFvcs=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 17 Nov 2020 13:10:05 +0000 X-SMTP-Protocol-Errors: NORDNS To: Daniel Kahn Gillmor , LAMPS WG References: <8c41c095-b826-b0bb-842d-76e0ef593d9c@isode.com> <878sb7gss6.fsf@fifthhorseman.net> <878sb0citz.fsf@fifthhorseman.net> From: Alexey Melnikov Message-ID: <9b513289-2d8c-8453-8984-88318d4e9950@isode.com> Date: Tue, 17 Nov 2020 13:10:04 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: <878sb0citz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [lamps] Proposal to adopt "Guidance on End-to-End E-mail Security" (draft-dkg-lamps-e2e-mail-guidance-00) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 13:10:08 -0000 On 17/11/2020 11:40, Daniel Kahn Gillmor wrote: > On Wed 2020-11-11 22:26:01 -0500, Daniel Kahn Gillmor wrote: >> On Tue 2020-11-10 18:20:43 +0000, Alexey Melnikov wrote: >> >>> I would like to propose that this document >>> [draft-dkg-lamps-e2e-mail-guidance] to be adopted by LAMPS. It will be >>> a dependency for the Header Protection draft and I think 2 drafts have >>> complementary scopes. > [=E2=80=A6] >> As the initial author of the draft, i'd be happy to have it put under >> the aegis of the WG, and i think it's definitely relevant here. I also >> volunteer to be the editor of it if it's adopted, and am willing to >> shape it according to the consensus of the WG. > in the WG meeting today at IETF 109, Russ suggested that we might need > some additional text in the charter to be able to adopt this draft. > > I'm proposing the following addition: > > 4. Provide concrete guidance for implementers of mail user agents to > promote interoperability of end-to-end cryptographic protection of > e-mail messages. This may include guidance about the generation, > interpretation, and handling of protected messages; management of the > relevant certificates; documentation of how to avoid common failure > modes; strategies for deployment in a mixed environment; and test > vectors and examples that can be used by implementers and interop > test suites. A more robust consensus among mail user agent > implementers should result in more usable and useful cryptographic > security guarantees for users of the tools. This looks good to me. > Note that this ought to be sufficient to cover both the > e2e-mail-guidance document discussed in this thread, and also > draft-dkg-lamps-samples discussed in this list over the last week, if > that one wasn't already covered (some folks seem to think the > lamps-samples draft is already at last implicitly covered by the current > chartrer; this would just ensure that it's explicit). > > If anyone has any concerns, or suggested edits to this charter addition, > i'd be happy to see them. > > Regards, > > --dkg From nobody Tue Nov 17 07:09:24 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380A53A1026 for ; Tue, 17 Nov 2020 07:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo9kOYY5dnht for ; Tue, 17 Nov 2020 07:09:21 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 194D73A15CB for ; Tue, 17 Nov 2020 07:08:45 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id m65so15731474qte.11 for ; Tue, 17 Nov 2020 07:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=Ar7ja6owp4AsG0Aqo/fokaHyzrQWF4PmbHdCroaej1I=; b=lziSKbPFQcx11c64zMCwF84iSWQT3Iff0kqBxje5QLDCaIUcOEeFHizmk/OlYGICsn f6e90ctq1Pg4lpwYZ4Q6JqlXfeb4qlBcUTAzomQ4hKB0qkuL9MGlwlz8kEs6oT398hc2 /tqSHNKa0c55A0eW/qmY54OZHLFZPXQYmUR0SBd6vM7WuI9BW0kTgmcwlXmEmNyesvNz fKj2ZUW/wX76hMYkHwl+TemuRze1oRcuDh9rGiQKxl6Gmi8JYT0PCq0QxD6HjNkPxH6f osP9UcQFkkzxo+zPY88L8p6JD99tBoHZyWuyyofu1w6tr4nD/B3dsshaJ3w4zyimy9Gk PjdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=Ar7ja6owp4AsG0Aqo/fokaHyzrQWF4PmbHdCroaej1I=; b=JMfVeqjWRUp3sVQ4HFHPjJYvkRwPr89kEsxCHrC7k4ZLPyMEyCTLu1npmjQpHOUA9n AlKceH1S+XA8Y9Xmw/VLMTIHVoE9ui9VoHylIyNukjbQuimUVwV9Twggzw+OKE5qErTP t1Hgg8TgekwSNRHXKIW9eqOXpch3C49CIFCQAubdGmJEuSVZ/Qjowfzzl0XsiMYZwpKO Abp5b3nrArNB0yZioGdhQt1HdFR69ivRWi3uG88JLz3fd0JsVEZIlMeJx1ksl4G9ms0w 0Y7uXO/laicY0HSnzyIWTtAA/ZnOujmRdwAfZwaLSf7bl7PAv5anQwHrwk9vuA5kStQI xzOQ== X-Gm-Message-State: AOAM532+k/DbSG5hwMycAPMIFDiuSrf75UVMy44e7l6qfDhO3todmHBo qxH7tfcWOgwQnv/Lctwem+s= X-Google-Smtp-Source: ABdhPJyJzedKg3caXXBuyNXULKEjYEXiSrYsDfyW2YWOOHcRdfsI1tHr+LEACUhwexy9bBWvwWUSfw== X-Received: by 2002:aed:2c46:: with SMTP id f64mr93277qtd.202.1605625724103; Tue, 17 Nov 2020 07:08:44 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id r125sm12937541qke.129.2020.11.17.07.08.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 07:08:43 -0800 (PST) From: "Santosh Chokhani" To: "'Deb Cooley'" , "'LAMPS WG'" Cc: "'Daniel Kahn Gillmor'" , "'Jonathan Hammell'" References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> In-Reply-To: Date: Tue, 17 Nov 2020 10:08:41 -0500 Message-ID: <0fab01d6bcf3$898a37e0$9c9ea7a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FAC_01D6BCC9.A0B78B40" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMGb7PLGIUkstBph5ynWWmikEzkwGcA6vJAUgCblYA8vKfOwG3tgbYAqF2tfQDFQgJDgI0H83XAoeDFRICV3NuxAGzC2AwAdwIV0gBjlAClaimAseQ Content-Language: en-us Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 15:09:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0FAC_01D6BCC9.A0B78B40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Deb, =20 This conversation is about consumer of the certificate and not producer. = What I wrote in the revised one is the semantics per definition of the = anyExtendedKeyUsage OID and that is how COTS work. =20 The consumer semantics cannot be dictated by what someone may wish. =20 From: Deb Cooley [mailto:debcooley1@gmail.com]=20 Sent: Tuesday, November 17, 2020 4:08 AM To: LAMPS WG Cc: Daniel Kahn Gillmor ; Santosh Chokhani = ; Jonathan Hammell Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? =20 I would not include the anyExtendedKeyUsage EKU.... The pro/con of the = anyEKU is that you can use the key/cert for anything. If that is what = you desire - it is a 'pro'. If you wish to constrain the use of a = key/cert, it is a 'con'. =20 =20 My current employer does not allow the anyEKU to be populated. We = consider it to be a 'con'. YMMV =20 Deb Cooley =20 On Tue, Nov 17, 2020 at 2:08 AM Jonathan Hammell > wrote: DKG, Small correction to your Peer Certificate Selection text below. On Mon, Nov 16, 2020 at 3:27 PM Daniel Kahn Gillmor > wrote: > To select such a certificate for a given destination e-mail address, = the MUA should look through all of its known certificates and verify = that *all* of the conditions below are met: > > - The certificate must be valid, not expired or revoked. > - It must have a subjectAltName of type rFC822Name whose contents = exactly match the destination address. > - The algorithm OID in the certificate's SPKI is known to the MUA and = capable of encryption. > Examples include (TODO: need OIDs) > - RSA > - EC Public Key > - EC DH > - If keyUsage is present, the key agreement bit must be set > - If extendedKeyUsage is present, the e-mail protection OID must be = present. The criteria "If keyUsage is present, the key agreement bit must be set" only applies to EC Public Key and ECDH. In the case of an RSA certificate, the keyUsage should have the key encipherment bit set instead (since it is used to encrypt the content encryption key). Jonathan _______________________________________________ Spasm mailing list Spasm@ietf.org =20 https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_0FAC_01D6BCC9.A0B78B40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Deb,

 

This conversation is about consumer of the certificate and not = producer.=C2=A0 What I wrote in the revised one is the semantics per = definition of the anyExtendedKeyUsage OID and that is how COTS = work.

 

The consumer semantics cannot be dictated by what someone may = wish.

 

From:<= /b> = Deb Cooley [mailto:debcooley1@gmail.com]
Sent: Tuesday, = November 17, 2020 4:08 AM
To: LAMPS WG = <spasm@ietf.org>
Cc: Daniel Kahn Gillmor = <dkg@fifthhorseman.net>; Santosh Chokhani = <santosh.chokhani@gmail.com>; Jonathan Hammell = <jfhamme.cccs@gmail.com>
Subject: Re: [lamps] WG = adoption of draft-dkg-lamps-samples ?

 

I = would not include the anyExtendedKeyUsage EKU....  The pro/con of = the anyEKU is that you can use the key/cert for anything.  If that = is what you desire - it is a 'pro'.  If you wish to constrain the = use of a key/cert, it is a 'con'. 

 

My current employer does not allow the anyEKU to be = populated.  We consider it to be a 'con'.  = YMMV

 

Deb Cooley

 

On = Tue, Nov 17, 2020 at 2:08 AM Jonathan Hammell <jfhamme.cccs@gmail.com> = wrote:

DKG,

Small correction to your Peer Certificate = Selection text below.

On Mon, Nov 16, 2020 at 3:27 PM Daniel Kahn = Gillmor
<dkg@fifthhorseman.net> wrote:
> To select = such a certificate for a given destination e-mail address, the MUA = should look through all of its known certificates and verify that *all* = of the conditions below are met:
>
> - The certificate must = be valid, not expired or revoked.
> - It must have a = subjectAltName of type rFC822Name whose contents exactly match the = destination address.
> - The algorithm OID in the certificate's = SPKI is known to the MUA and capable of encryption.
>  =  Examples include (TODO: need OIDs)
>   - = RSA
>   - EC Public Key
>   - EC = DH
> - If keyUsage is present, the key agreement bit must be = set
> - If extendedKeyUsage is present, the e-mail protection OID = must be present.

The criteria "If keyUsage is present, the = key agreement bit must be
set" only applies to EC Public Key and = ECDH.  In the case of an RSA
certificate, the keyUsage should = have the key encipherment bit set
instead (since it is used to = encrypt the content encryption = key).

Jonathan

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

------=_NextPart_000_0FAC_01D6BCC9.A0B78B40-- From nobody Tue Nov 17 09:35:45 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523033A14E7 for ; Tue, 17 Nov 2020 09:35:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=GM4Kqr4T; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=05rvuRcr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlTInjGmo_yq for ; Tue, 17 Nov 2020 09:35:42 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EC0A3A14AA for ; Tue, 17 Nov 2020 09:35:42 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605634539; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=0B/zKxLW10S3EHtUMGtNLRSyfvyKhhHIg8exBr74hWE=; b=GM4Kqr4Tp79X8C9BXnFnwmnpb0jrOtEmW60dvybvhScHl0h9ELO78BgwUGFNuuN7WhvhU lPVw2a1Dz09Zp77Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605634539; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=0B/zKxLW10S3EHtUMGtNLRSyfvyKhhHIg8exBr74hWE=; b=05rvuRcrpxie6mXD8YRckjnHkMjbBkHQg/PPXGJ2449SdgJJo22K3PlpUThDWg3TEGHIZ l8dM/4XbEkeHwOVHyRSMkMfDosxacHIzc5k/PrfQU/rcdkfR1QHr70rXliYAmT+0kYRMsRm Xa0wL4LjbO1IU6iF9yH3sBRQNll3EEkZe59zUf/iAot6lbvfxou1h7eojAHNxa9nJYYDaUG Z4PzI2wXWqGItklC2sMw2gF+HMUcmyn+QEOK8BfE4pXlBrkMvnSxq5Ed6UXZACx8iqXQ/zh OvwFrtUNuJGCqdOaS3djVNpan8REJbGpdx57yTYYHdKWyoAjUlXwkKfZaljA== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 16927F9A5; Tue, 17 Nov 2020 12:35:39 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 1E58F20316; Tue, 17 Nov 2020 12:35:36 -0500 (EST) From: Daniel Kahn Gillmor To: Russ Housley , LAMPS In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 17 Nov 2020 12:35:35 -0500 Message-ID: <871rgrdgyg.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 17:35:44 -0000 --=-=-= Content-Type: text/plain On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information. As a > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation information available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to have to check for? The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP responder for a certificate is published in (and looked for by the relying party in) the *issuer's* intermdiate CA certificate, but is *not* expected to also be published in the certificate itself, then we'd need (b) for the CA to be able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't know about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two options for finding the OCSP responder location are (1) in the certificate itself whose status is being checked, or (2) "configured locally at the OCSP client". If the only scenario anyone can produce is "configured locally at the OCSP client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to match on a different set of certificates. Introducing redundancy (and room for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7QJ5wAKCRDEDyVUMvKB D68KAP9K/ef/ZHN75WuuHserHutS6Ip6N9kzySB/E6YSDTU4RQEA6MTCkxjjA4JD 3HIkyoXa3w5QopNA2lWOTB7q6D0hGg0= =NLxD -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 09:58:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAE43A12EC for ; Tue, 17 Nov 2020 09:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 51jh51WkX-3k for ; Tue, 17 Nov 2020 09:58:20 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 B44653A14E6 for ; Tue, 17 Nov 2020 09:58:20 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id g15so16321406qtq.13 for ; Tue, 17 Nov 2020 09:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=LLedOyPw8FXK//ccurssxIz/jOsuvIJSbJtPPqZ3kzs=; b=e+E/nUIixwcXcanYMzIxA9L8RmN/L3FxFoCIMi4/RoCjqYk13hH9Sa3lRGQGG9PkBQ qoZmJmTkRmL99p6R/SzAE2uCvNCpkU/A66kX3FXZKPUC8Npjn4xlasQV+HKGDoDhI0Ze ZqdbrzMx5F7VbLX78uE2yKkMBJPHmokOF7fZ/yR7aKVYysu9SEi4D3CrAMBVY2rmmA/P go5TB38qTcy57HjLiTNK9svSC3uKckbNOhZxbqkUh9nkyl7THSsUdTuBi4klbyQKjGhQ Gpmxb9XKo7cB/Hvv5sWeo90213nyHQIISQhKh+skKn42CEp4/QuiQoryYvNAMsEdstjh ivuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=LLedOyPw8FXK//ccurssxIz/jOsuvIJSbJtPPqZ3kzs=; b=e42FVmdW+ms6lQoEV4jGbfAKL3nwQEjdU2O29QKc/sE+FA6DFatFmhr+lZ3NE5jXr3 R4FD3wwxoBmGZwHhUjPHtaKJNk67BqA01svjSeME0/3SkRkyywoZ74lB2EOd3v1bW9NY mfl/Vmxfny2YF5C2/WQzrnnMW7naoz0dWMAaNSdA6wR+5rt0X9mCdCj8rd+luRQ9DF2b uxf54/B4cM6hYdOezRA6jJkyLlviNXCHlB33vq1gaCMwC8Bq2qZAizwNn2jhArxA0INV DPRTTfj2MNthntILKA2Ibl9R7+6euQxg2k3ZisHWtIT1rcDvbTE2aY9+WQJi4mVy4pnB Pt8w== X-Gm-Message-State: AOAM530Vf1S6pr6XjwgD71rs+KivMIpsxZ/mxMuMOz3pdI5l3glECYP4 cXL/AlNRDjlSiXFHDhPeuzRMjd1Hp4M= X-Google-Smtp-Source: ABdhPJyNu+h9IZt8EtirX6yKalscnirsyC68wgV3Uigzup9jPnfnIkp72xU+RJ0ca/c/DOhndNwMNA== X-Received: by 2002:aed:3263:: with SMTP id y90mr355723qtd.196.1605635899289; Tue, 17 Nov 2020 09:58:19 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id y35sm10898008qty.58.2020.11.17.09.58.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 09:58:18 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS'" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> In-Reply-To: <871rgrdgyg.fsf@fifthhorseman.net> Date: Tue, 17 Nov 2020 12:58:17 -0500 Message-ID: <102d01d6bd0b$3a880150$af9803f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFRMB+BZSggHDnm7QAg4XNZ0C7X263wGuXXnVAcI99H+qm/QokA== Content-Language: en-us Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 17:58:23 -0000 DKG, This determination should be based on how client behaves when no revocation information can be obtained. As to OCSP client policy, clients can go to responder(s) that are locally configured (causing delays) and come back with no tangible information. The question boils down to do you want client to continue and without any warning or anomaly? If so, that should be indicated in the certificate and not by omission of CRL DP and OCSP. Again, the client needs to process that indication to mean all is well. I also do not see a need for both extensions. No-check might not work with COTS because some existing clients may deal with it for OCSP responder delegated certificate. If this is a client you have control over, I would say you can make either extension work. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Tuesday, November 17, 2020 12:36 PM To: Russ Housley ; LAMPS Subject: Re: [lamps] The id-ce-noRevAvail extension On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information. As a > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation information available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to have to check for? The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP responder for a certificate is published in (and looked for by the relying party in) the *issuer's* intermdiate CA certificate, but is *not* expected to also be published in the certificate itself, then we'd need (b) for the CA to be able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't know about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two options for finding the OCSP responder location are (1) in the certificate itself whose status is being checked, or (2) "configured locally at the OCSP client". If the only scenario anyone can produce is "configured locally at the OCSP client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to match on a different set of certificates. Introducing redundancy (and room for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently. --dkg From nobody Tue Nov 17 11:25:05 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF0E3A1579 for ; Tue, 17 Nov 2020 11:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=3zTH20pC; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=CHa/6wcP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mh9s2dezmXo for ; Tue, 17 Nov 2020 11:25:01 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDB3A1392 for ; Tue, 17 Nov 2020 11:25:01 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605641099; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BhQs8ASOUf1/JosLjbpCqASEHG5kY/Pw408gcIa6Pqo=; b=3zTH20pC8ANXe2mBeEWA7JV8W8v7cWGIwqH6gWr3xvTHf9Ag7GkFzdkU1Ejx4kHOOFud1 ZB53QzGla0kF9jBAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605641099; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=BhQs8ASOUf1/JosLjbpCqASEHG5kY/Pw408gcIa6Pqo=; b=CHa/6wcPHYbHyTDVUBHAfkaEOe3rUl4LTrECXYwdvDVkInwdkujCK+paVEpHPWvMnfVtZ rgfEKheAU66Ja+Rxo7rhGxKmLQLRHa65W2O5vEUczZaY/Jjgsj6ZJUaRACr3YPMPLg+3dyS 3muLA+1f1F14rHqNrqvmjQ5MQsIh11ALgBzsEkZ37FvULT4Hu3HXS3DqMD6K6ZGvP+2zNCc 6PJGUFLjKE82IRqBamorHXQnR8wGkRyoXqT2x7Sy9XbR4M6w9n4mt4wpB3ysFYUwfk5hwpx bqIaf138BtYXBp5hJiSce9lJcKmrHPSZK82EKMotLSm/b3lmDUDFXFf7MeAw== Received: from fifthhorseman.net (unknown [192.168.183.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 857ECF9A5; Tue, 17 Nov 2020 14:24:58 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id B3C642043F; Tue, 17 Nov 2020 13:29:47 -0500 (EST) From: Daniel Kahn Gillmor To: Santosh Chokhani , 'Deb Cooley' , 'LAMPS WG' In-Reply-To: <0fab01d6bcf3$898a37e0$9c9ea7a0$@gmail.com> References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> <0fab01d6bcf3$898a37e0$9c9ea7a0$@gmail.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Tue, 17 Nov 2020 13:29:46 -0500 Message-ID: <87y2izbzvp.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 19:25:03 -0000 --=-=-= Content-Type: text/plain On Tue 2020-11-17 10:08:41 -0500, Santosh Chokhani wrote: > This conversation is about consumer of the certificate and not > producer. What I wrote in the revised one is the semantics per > definition of the anyExtendedKeyUsage OID and that is how COTS work. > > The consumer semantics cannot be dictated by what someone may wish. no, but they *can* influence the guidance we give to certificate producers, and at some point certain semantics do need to be deprecated. we can't just claim that they'll work at all times. One of the best ways to discourage producers from taking certain actions is to ensure that those actions won't be accepted by some noticable portion of consumers, so pushing for changing consumer semantics isn't (or shouldn't be) out of bounds as we try to move the network to better cryptographic practices. That said, for the purposes of draft-dkg-lamps-e2e-mail-guidance today in 2020, i propose to document the current semantics for the consumer (that is, accepting anyExtendedKeyUsage as documented), but also to encourage the MUA implementer to warn the user (and encourage them to complain to their CA?) if their *own* certificate has such a flag set (or has multiple usage flags set that indicate that the same cryptographic material would be used for more than one purpose). How does that sound? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7QWmwAKCRDEDyVUMvKB D8ogAQCewe7xP7sp7oCzwYTgQELYY86nWibu+mjv07CwEUBQiQD/bgP8ckKjfvKn nDGztgSg+ttf+l1HJeUOiAIDSh1TTgI= =pNt8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 17 12:04:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC973A0639 for ; Tue, 17 Nov 2020 12:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 K7wHaDFVUkcX for ; Tue, 17 Nov 2020 12:04:04 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 C39F73A0769 for ; Tue, 17 Nov 2020 12:02:46 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id e14so4221382qve.3 for ; Tue, 17 Nov 2020 12:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=k/B+jpQWaROxi1gqrdc2Isa+Ky/E84W9scJ774s+364=; b=UAQK8DVHFN6YGzLD/AMS2wnl2bcMRWDriHB4sSyjM3YdldlGeZOGYXEqfZwbust1Bi XjQuiY9oEqM/Vm5grNqYzkG8fpkoG/1mpoS/3vIy0Sh5PGGwG11OOm6Yy/1HJVmbr2AJ HCuydxKbOSeE2GxYBoS/oo9cT+7xf5kcsCKoUIguaFULaziDV+D1ch+H+iVfO6R2eSo3 x0sEdZskNhtoWOzQaHU9s3tpk4e3jneOvVhMMj0lvGPEx8J1/OdH+XQayk5Os0hjD37o Q+Tw7Ivgxa9DraN7O3y8Ng9zP7z3p/LuFyvmGzzn1lLx6ct9adXM6EhHZIzwe8+SROgu +QxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=k/B+jpQWaROxi1gqrdc2Isa+Ky/E84W9scJ774s+364=; b=EnJq0EnR+N2q6NvFfAoLYVroXtSBwGD+WyxZ1YBOu2TPftkPAiTNLgpQwR3rzvMc1e M1ukGKlFxVsUx6buQBb8QTISZU1LV1G3VBJrUtjOXXRNJ+Gs2pPCpWzkL8hq/QXNCtvm 0S4N5Kw8xrBtcSJM5ylC9oUKHP4lZj7aX7E5Bv5hul8pNFG/Bd9G6U1pLP1AhiQ/leHJ lLpF7o1EA/D/SOacCfQSZrA9Mg9z/g+ySFNnvxPjHgp3dSmFoN+rw7Wax70UGdFchjsa RCE74E53nwyOCR+wn0oJXQ6Teqx1+/XONnne63xrIsqaOiy+1SmlrSBkpASlac1IyF4y k4yg== X-Gm-Message-State: AOAM530KgOqmHZuOMWMZVmj9XFT6QuY7Rigr4aqwH2ABaAiW+bDvj0CD 7YKjlo6G6FEXtN0Q5aCPJEh6TN5CyfU= X-Google-Smtp-Source: ABdhPJz7V0/+KP3V1FtBUyJoplJXNuOkrMl53R707/gf1+ux4FZu+UR22DpjiRyiv/OF3A54VRUMfA== X-Received: by 2002:a0c:ecc1:: with SMTP id o1mr1004395qvq.6.1605643365496; Tue, 17 Nov 2020 12:02:45 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id 9sm13805345qty.30.2020.11.17.12.02.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 12:02:44 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS WG'" References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> <0c1001d6bc40$16a37bf0$43ea73d0$@gmail.com> <873619dph0.fsf@fifthhorseman.net> <0fab01d6bcf3$898a37e0$9c9ea7a0$@gmail.com> <87y2izbzvp.fsf@fifthhorseman.net> In-Reply-To: <87y2izbzvp.fsf@fifthhorseman.net> Date: Tue, 17 Nov 2020 15:02:43 -0500 Message-ID: <111901d6bd1c$9caaedf0$d600c9d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIMGb7PLGIUkstBph5ynWWmikEzkwGcA6vJAUgCblYA8vKfOwG3tgbYAqF2tfQDFQgJDgI0H83XAoeDFRICV3NuxAGzC2AwAdwIV0gBjlAClQNnDmiLAlA0pquoeJmxgA== Content-Language: en-us Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 20:04:06 -0000 DKG, For producers, if you like, I can define recommended and not recommended syntax. For example I would recommend the use of EC Public key and NOT recommend ECDH in order to enhance interoperability. For key usage I would recommend inclusion of the extension with criticality set and with key agreement bit set and DS bit may be set for dual use, but not recommended. Other bits must not be set. For EKU, I would recommend criticality not set and inclusion of e-mail protection OID and recommend NOT including anyExtendedKeyUsage OID. Other EKU OIDs may be included consistent with Key Usage and intended usage of the certificate. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net] Sent: Tuesday, November 17, 2020 1:30 PM To: Santosh Chokhani ; 'Deb Cooley' ; 'LAMPS WG' Cc: 'Jonathan Hammell' Subject: RE: [lamps] WG adoption of draft-dkg-lamps-samples ? On Tue 2020-11-17 10:08:41 -0500, Santosh Chokhani wrote: > This conversation is about consumer of the certificate and not > producer. What I wrote in the revised one is the semantics per > definition of the anyExtendedKeyUsage OID and that is how COTS work. > > The consumer semantics cannot be dictated by what someone may wish. no, but they *can* influence the guidance we give to certificate producers, and at some point certain semantics do need to be deprecated. we can't just claim that they'll work at all times. One of the best ways to discourage producers from taking certain actions is to ensure that those actions won't be accepted by some noticable portion of consumers, so pushing for changing consumer semantics isn't (or shouldn't be) out of bounds as we try to move the network to better cryptographic practices. That said, for the purposes of draft-dkg-lamps-e2e-mail-guidance today in 2020, i propose to document the current semantics for the consumer (that is, accepting anyExtendedKeyUsage as documented), but also to encourage the MUA implementer to warn the user (and encourage them to complain to their CA?) if their *own* certificate has such a flag set (or has multiple usage flags set that indicate that the same cryptographic material would be used for more than one purpose). How does that sound? --dkg From nobody Tue Nov 17 16:05:42 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD643A109C for ; Tue, 17 Nov 2020 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 lzFGKyCIbdHe for ; Tue, 17 Nov 2020 16:05:38 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C8BC33A109A for ; Tue, 17 Nov 2020 16:05:38 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id v143so146933qkb.2 for ; Tue, 17 Nov 2020 16:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=7O7TuYUXDqLtGlikLz2Hia+RJYJ7fVrNWfi+AzOE+kQ=; b=pLfd4MPd5oMOAmFrrP8Mc+IGApcV9PzlXeUAL8/NOYlRtwjO0uRFaONELOGIfcmSt/ YYGvwTFRQa76spIJmre4KKVh3d7RzxMNs7HMyKra1oqz4TRkGbdretoQx6MmDTDuRxS6 /HzYOTfW15gHIcw+9TzMHLfpW/tKohvlOw1WtqjOGYgMQqKuXduBKiYOg6sMB1qGz8Vi WNLI4Y7WxRcOBd1A6a6+04gng2CBvjgzCtSE4BUYhmEIJ6nWVq33z52fLt93226G/tX+ jp6BPz8vYU0/1RwzVpmnXqm+TvGxzqPhJynwyeVlqe1lyJFIDaccVqwruvKyKHYljfgB WgwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=7O7TuYUXDqLtGlikLz2Hia+RJYJ7fVrNWfi+AzOE+kQ=; b=LLihT1CGRtfPjuZh6N21593UuPM8z015kFFmNJgw01ADUmqniCnXyjqQM1ERWesifx 8/hmc8zUSqoDjUWKicTEOfJwrdtIsoYqjK0+Dt9CHxqK0fV/iJ14C3pwx3ws9ERi8L6/ kvLBMQ7cxZot+xyx3WcRH2vuVdyWrmgxLWH/LGMNrmtLMGC5uPynAFHhU3x9foqyRf5S OUTUMI2RLgJCaDYHFtaGlW7l4Fw46eY1s+qvE5RMCMGpPPTq1mF1mOdEA7O1DKpm4ZHo hmdVpkpw2Qmc7FeZvqTc7J0MvhlgulfF9RvCzEuuBkw5/62KqH27OcjRkb7wwlUWjLlz gKvA== X-Gm-Message-State: AOAM530f9C8jlvPdLruDOrzjyQpT5J0T8Fm1avkVZoZ9REhMwKfcIByd FGX2giH+q7W3gXCie0+OP0ZP9FsTXlk= X-Google-Smtp-Source: ABdhPJwskWT80G6Jvym0RUJxsEYkRMvZM+pr09GRa6mFUz22PbRBV585SIo7UnHIKV0UbOZ3hMVNRA== X-Received: by 2002:a37:a9ca:: with SMTP id s193mr2229778qke.313.1605657937568; Tue, 17 Nov 2020 16:05:37 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id o21sm16104036qko.9.2020.11.17.16.05.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2020 16:05:36 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS'" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: Date: Tue, 17 Nov 2020 19:05:35 -0500 Message-ID: <124f01d6bd3e$8a494d10$9edbe730$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFRMB+BZSggHDnm7QAg4XNZ0C7X263wGuXXnVAcI99H8C52Ev9QH34teoqnVgybA= Content-Language: en-us Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 00:05:41 -0000 Mike, Recursion in OCSP check is avoided by simply asserting OCSP-nocheck in delegated OCSP Responder certificate. noRevAvail obviates revocation checking for attribute certificate. Neither fit a TLS Server, TLS Client or E-Mail client. It will all be a function of how relying party software behaves if either one works. I suppose asserting both is saying I hope RP gets one of the two in the context of a certificate which is neither attribute certificate nor delegated OCSP Responder certificate. I would like to review DKG I-D and I-D scope to figure out if I can provide any helpful suggestion. -----Original Message----- From: Mike Ounsworth [mailto:Mike.Ounsworth@entrust.com] Sent: Tuesday, November 17, 2020 6:48 PM To: Santosh Chokhani ; 'LAMPS' Subject: RE: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension Unless I'm missing something, another concrete use-case for allowing id-ce-noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow OCSP over HTTPS (unless there's another way that I'm not aware of to break the recursive OCSP checks loop). Clients for this use case would be "anything web". --- Mike Ounsworth -----Original Message----- From: Spasm On Behalf Of Santosh Chokhani Sent: November 17, 2020 11:58 AM To: 'LAMPS' Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. DKG, This determination should be based on how client behaves when no revocation information can be obtained. As to OCSP client policy, clients can go to responder(s) that are locally configured (causing delays) and come back with no tangible information. The question boils down to do you want client to continue and without any warning or anomaly? If so, that should be indicated in the certificate and not by omission of CRL DP and OCSP. Again, the client needs to process that indication to mean all is well. I also do not see a need for both extensions. No-check might not work with COTS because some existing clients may deal with it for OCSP responder delegated certificate. If this is a client you have control over, I would say you can make either extension work. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Tuesday, November 17, 2020 12:36 PM To: Russ Housley ; LAMPS Subject: Re: [lamps] The id-ce-noRevAvail extension On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information. As a > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation information available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to have to check for? The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP responder for a certificate is published in (and looked for by the relying party in) the *issuer's* intermdiate CA certificate, but is *not* expected to also be published in the certificate itself, then we'd need (b) for the CA to be able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't know about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two options for finding the OCSP responder location are (1) in the certificate itself whose status is being checked, or (2) "configured locally at the OCSP client". If the only scenario anyone can produce is "configured locally at the OCSP client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to match on a different set of certificates. Introducing redundancy (and room for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently. --dkg _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Nov 17 21:18:58 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1883A1431 for ; Tue, 17 Nov 2020 21:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DqbygUYDcFEC for ; Tue, 17 Nov 2020 21:18:55 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6993A1430 for ; Tue, 17 Nov 2020 21:18:55 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id q206so854499oif.13 for ; Tue, 17 Nov 2020 21:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uNZRwgi8S4suwFhqAH4DTk768WAL3Ui/qdug2Z+p/g0=; b=eGaPQDkScpxs6JQE1OFA1r+26rHn5Anyj09u27eHV9YgAFimOQjET2iXAr33GC0yfU nt2NoJXgSyKfY7bjhWIMSErRkC+/1UC0kS0YkIQ1doCNy9O5E0dmTEzS8nMO9zeN1Me8 2+6Ix3eEYFO8eYis3YR3h4AzOZYzj/RDVrlsUdo0azTob9ilQbyrPflXYrHIS1br2yvm Twwdkc+HT/RBquDHEuXgCiJALYB135Wm/S5DU6+DljKuk8Bc+vbs4BPb7ZRhGBFyy/UG 7x+vs8SRCN0DM8PsfJcPVykoGg94eERz/DOshVE54Swcvm6hLNsCyHYMc8R36I2a4qky mw+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uNZRwgi8S4suwFhqAH4DTk768WAL3Ui/qdug2Z+p/g0=; b=BvOl7m/bacQddlqcMxjQiheo0EXRECCjnRegFprT54XVoZJ60feMZE34C3oNNolHZe AXq18XoyuHNnX7fepUXeoFs/cIZqLKMJ8HxlzPYqsetjXRBAiqgs7kjX7PkPa7fd7zFR fDyGR7E1yNPcB/T0RpWdjOnPxtJcyrVDSwIpC+F9fCT0TTUPsNPHeAtarJLibY/MPvcM //ITuzXneTqR2B8dUkFwVp8w5n/nS2omgBR1Yau3jBqjXEs/+U9YDQsgeimDNeLKuZrL RD7CxTlEMjtIcVuGjHaQcZ+Il249wVHifLb/w6cZISYw1QHXhevldudNJ5xgVC1K+v3j hSCg== X-Gm-Message-State: AOAM531LkDsZtqLkIa5YmhWr8pA6r+3znoS0tp1JQ/GNdNPX1J7M96yU xU6ofkSt74e8O/i7xUlRy9cxfIFMOP0yjNyQUzA= X-Google-Smtp-Source: ABdhPJxbKk9XZcvZzy90S3oLA+PBnUxyS53f6OjWqDJzgKpE1tuEdn6ck+ZL1ti3PlmnWdNcgjRUkZMeXfrnvzVuwnM= X-Received: by 2002:aca:c2d5:: with SMTP id s204mr1628199oif.143.1605676734670; Tue, 17 Nov 2020 21:18:54 -0800 (PST) MIME-Version: 1.0 References: <87361pjjtu.fsf@fifthhorseman.net> <8465.1604507476@localhost> <87v9elhsup.fsf@fifthhorseman.net> <833.1604521111@localhost> <87o8kbj1oi.fsf@fifthhorseman.net> In-Reply-To: From: Jonathan Hammell Date: Wed, 18 Nov 2020 00:18:43 -0500 Message-ID: To: Henning Krause Cc: Deb Cooley , LAMPS WG , "Cooley, Dorothy E" , Michael Richardson , Tim Hollebeek Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ? X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 05:18:57 -0000 Dear Henning, On Mon, Nov 16, 2020 at 12:24 PM Henning Krause wrote: > indeed NIST says we must not use the same keys, but the RFCs are not that clear: > > RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC certificates certificates (i.e. with algorithm identifier id-ecPublicKey, but also with id-ecDH or id-ecMQV). > > But the encryption with ECC uses ECDH, and per RFC 5280, ECDH should fall under the keyAgreement usage, or am I wrong? > > I can't find anything in those RFC that would forbid me to use the same certificate for signature and encryption. > > Did I overlook something? No, I am not aware of any RFC that prohibits using an ECC certificate for both signing and encryption. As I pointed out earlier, RFC 5480 says that any combination of the key usage bits MAY be present, subject to the restrictions previously discussed. Those restrictions do not forbid using digitalSignature and keyAgreement together. However, NIST SP 800-57-1 is an informative reference in RFC 5480, so I still recommend following that guidance despite it not being explicitly required or recommended in the RFCs to do so. The PKIX RFCs are not BCPs. The CA/Browser Forum has recently established an S/MIME Certificate WG to create baseline requirements for this use case. I am not involved, but I believe that one of the LAMPS chairs, Tim Hollebeek, may participate in that WG. I will be surprised if they will not require separate certificates for signing and encryption, but Tim may be able to comment. Best regards, Jonathan From nobody Tue Nov 17 22:32:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B7B3A1044 for ; Tue, 17 Nov 2020 15:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=dGt0RLVI; dkim=pass (2048-bit key) header.d=entrust.com header.b=OagOIGRg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYsrofEoVLFD for ; Tue, 17 Nov 2020 15:47:43 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 97EC03A1033 for ; Tue, 17 Nov 2020 15:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1605656863; x=1637192863; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=V2QOAqBWLbqbe41V3GFFzyFZZdToZ3+4gbnYivKSVjw=; b=dGt0RLVIxuHPdLMDRfKr94LlhXVBbf7Vfq84xrBW9EoC7rB0FwdnQBrC hGokN7EaVN3/GZPAmn7EpfkMbzr3yZwmi9UpUXElxmfdyl7n6IjUSZJj2 0oI8Hbl5INiD7Va57Yvw/DjgX/rl0hjO+ZV/wDqjzsKADzTI9QdCKPOsW OWft1OsasziDVLK0olvINX3yTAxbLIUddhjwxbMRfr+Ox7Q8C73affnfO WYQLepKRdj4roRd/2Ubrw/MFDOWw4r8E4lV9cPoqNyXBjiXVl0n8a4PAy NGtbEdPgOAC0WADxcbXx0ZGlZcgO+1NCdWWLyopvUDIpStYQEL8mKCbUl w==; IronPort-SDR: PaskZqsJ94bpQfYU1ewHcKf6FyvyMdEGcNU93jzGdiudDLPzZpK5PmnJnyRkuLRDDuZvfZuLXg xUhZDz/B3xIg== X-IronPort-AV: E=Sophos;i="5.77,486,1596517200"; d="scan'208";a="23677537" Received: from pmspex01.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.29]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Nov 2020 17:47:38 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 17 Nov 2020 17:47:33 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 17 Nov 2020 17:47:33 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hbkxlJhd0G8k7I/WzKaSOuGLx7pnO0IVOqeMX1ang1BAaZO6J5QQsMpX+6f92l6lV5W2Gvcj6mDhC6+sWSjeaupGJISJqNd4WyZcos16pY9KY3q0q5As58erfpPfhVAzlSttmKBnVHSxMwT4m2m1mJxDfpEeHUOvlEyW4TFOdBS93IYYOwoQZHBctSxS64T+qYQKDwbPBNs6Qt4lxSAXN2+Nxe9xfYjtBK4gY41hNe6UBr8r6Z6qKPOFRW835CeE82gv9ASK0S0Eh5i3mSoEhdl/xEXYKZpMWdIWCOK4gAKb0NDOHLIErwVEGODqyCGo2ZqBYRib93wk4GnOJyZalg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8oY+g+WMzZbNt6YqVP/djV6kdohLH3BaiQ6K4EhUiX8=; b=G9qJ1rqUkPAq7rQmtZAdXlNZbR62qg9ZsBOtNmnwXowINjH8/KJTDDw0R9wdCUPwoKoSJJGFTAyywZFsUuRYkC0zo9xeWVX/JbV+O8XITOWAyk82nJzNLPBjA978LXi+uVASqYpAvQxtZjnBfjWm/s+CJ/9io9rUntwd0lFGaFdcoU+jVarr/TluZyfMTCONMi0g2rOrd/NnXujPQzyQZGjD8gI7HyDKEkEitvipdGmVdyb6YR+K/ji/RV1xPIZ6WFjvqtMNRQ6JvdSfKONTd/Mn4E+6DfQR4qMoXzjdQkdoc2uO9CuqHdpcUJXXnvdLELpKyB6P8ny/7FQtIHVdTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8oY+g+WMzZbNt6YqVP/djV6kdohLH3BaiQ6K4EhUiX8=; b=OagOIGRgi9GDQiBUAayP5DNNQSrAWPMXiRBv0q3+5Uf5iKF3+qIhxOkbFPchCvgnuk44WDsl09eab3BwdKj4+gdADWgtIVbietoCflrk+JaXRNpnjm/KTgXRRMlmB9kgxKrrvIEPu9ZSAkFOnazqrAIVZevQhi8ffXhper5NLELJDIu1UoftVVF7NFkBMf0gDNAD0Q2NS3AtSlDZhnQV5TeZ5bS7e7E2VuFJ6Qo98j/wH/ixh97rJtm3j3E03h2gVW3ncZ1A2LNT7xhKFGWX3ewka01xXgLkzLgaQ1n2/DGnLBmchD6hQ2BA49Oee7TZo629mI1tOr4URMuiGzq+FA== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM5PR11MB1611.namprd11.prod.outlook.com (2603:10b6:4:9::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.25; Tue, 17 Nov 2020 23:47:31 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c%3]) with mapi id 15.20.3564.030; Tue, 17 Nov 2020 23:47:31 +0000 From: Mike Ounsworth To: Santosh Chokhani , 'LAMPS' Thread-Topic: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension Thread-Index: AQHWvLsz3sxA9XzW7UeRmWOCPJvrw6nMlqaAgAAGV4CAAF/TAA== Date: Tue, 17 Nov 2020 23:47:31 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: <102d01d6bd0b$3a880150$af9803f0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55e94dfc-7fc3-4d79-5974-08d88b532674 x-ms-traffictypediagnostic: DM5PR11MB1611: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UwgAlM3bOy0ANvIbBxWp669P2cj+RIs9wpxc9auvrjfNHNHhtGMp2xu5eLFHOOiSp2ePAHe7A8ZAB5Fb6EVrfZ7tFPldS2LxbieFZSXv5/nWlmhvm/q0C5ZY+pCrFgLvKWc52vqZGYJFf8Z2Tly7ExWs4bxqM77EW+eYLDlA/tkCmEWVn5jvR6yX5oWOQ8QWwGOtJiiG8gSBnPi0Ypu/65DGyeWD/fkyGJZUJtnzCLfXaR62f5dwHWE1nvN+W2mS+3Nzq6HLezXXtcZLWpd5ESqr8MdLypAUgjBHq+fqUtwa0xOHwZqPUH3IN677LxxIJO/uRXaKe+HVyDEYCS2SO3Kl601sH7z+Mp9EfCxbLvqGV/At8ylgir4xpPmeNB8CTB3CDe3AY6U71/Tj1ppgXw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(39840400004)(376002)(396003)(53546011)(2906002)(316002)(7696005)(66946007)(33656002)(86362001)(8936002)(66556008)(64756008)(4001150100001)(186003)(76116006)(110136005)(66476007)(71200400001)(8676002)(6506007)(26005)(66446008)(83380400001)(9686003)(52536014)(5660300002)(966005)(55016002)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Xw0BmzA6Z0Ofi9GiAE8j/xFqadoPSvtsegvTTnobSVnSKjZAIbAwAvy/3FwLvTW66GLBgITJXANEP4HIXzJYYkCCYGWTWngMTznplCY2LywmrneRsmHd7k+3aKPLMnW2qxcxZmXJ8OhhwDzs6CRqy6Fna3QAVHkZb7gtgd6SlJQT9Idv97BMJ3fUjngWqqXk1oyW8EVHTor4DToAes/ARBMqdSDJniU5jUm0dIlb60AbTXLCy6FETuJLapnXnd27NRjtPu/Eebg5nL4x4lNdV1ZKu+Sj6J5jaZYHQQZPWi+Zm2vVerOsqgWkHBD+0lUkXTW0m6+maiyGLbmfbTAI+PVwIAPcHx9YaevO0BOGiFHOg68r1FfsyNbSJhMJB1o//HUvdogby8Fg9vxD/JRNrUe3Z7Aqik8mQLPTGTAEulStVvrae0Mp0YeMUrKC8twBn71073tYNrCQcsbbeZOTc3TSdPgnSQCDsUOd12XyZ+H0grXmqBcVFs79g/Mp5b89291GnOK72hFb7U7bHb4WiNsRGXPEYdUXFACHUt0MKXJ7Qy+/LptAyv9CwDIlcPyfQ6f7PxbsYw+s9aKCywXVMkxYM5WNfT240YI/0Y4DLeNcgL0nl9xGYoC5Jc3dq49Bk74cGdbtRqmrXM6uAFrQ6w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 55e94dfc-7fc3-4d79-5974-08d88b532674 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2020 23:47:31.4841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZGn0j2O7sD479rlD23qpYqD3inrkbSxB29jSKzjylMCv5J8Islv+fBmWlV61K+clon1VEJgdctW3Y+klFxo04B01NkvGYlRwq3NsGH1nH9g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1611 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2020 22:32:25 -0800 Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 23:47:46 -0000 Unless I'm missing something, another concrete use-case for allowing id-ce-= noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow OCSP over= HTTPS (unless there's another way that I'm not aware of to break the recur= sive OCSP checks loop). Clients for this use case would be "anything web". --- Mike Ounsworth -----Original Message----- From: Spasm On Behalf Of Santosh Chokhani Sent: November 17, 2020 11:58 AM To: 'LAMPS' Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. DKG, This determination should be based on how client behaves when no revocation= information can be obtained. =20 As to OCSP client policy, clients can go to responder(s) that are locally c= onfigured (causing delays) and come back with no tangible information. The question boils down to do you want client to continue and without any w= arning or anomaly? If so, that should be indicated in the certificate and = not by omission of CRL DP and OCSP. Again, the client needs to process tha= t indication to mean all is well. I also do not see a need for both extensions. No-check might not work with= COTS because some existing clients may deal with it for OCSP responder del= egated certificate. =20 If this is a client you have control over, I would say you can make either = extension work. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmo= r Sent: Tuesday, November 17, 2020 12:36 PM To: Russ Housley ; LAMPS Subject: Re: [lamps] The id-ce-noRevAvail extension On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no=20 > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time=20 > needed to detect, report, and distribute revocation information. As a=20 > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation infor= mation available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also cr= eate an opportunity for confusion, because a single certificate can now cla= im an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to= have to check for? The only reason to push for (b) is if there is a legitimate case where a st= andard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP respond= er for a certificate is published in (and looked for by the relying party i= n) the *issuer's* intermdiate CA certificate, but is *not* expected to also= be published in the certificate itself, then we'd need (b) for the CA to b= e able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't kno= w about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the tw= o options for finding the OCSP responder location are (1) in the certificat= e itself whose status is being checked, or (2) "configured locally at the O= CSP client". If the only scenario anyone can produce is "configured locally at the OCSP = client," then presumably such a policy requires identifying *which* certifi= cates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to= match on a different set of certificates. Introducing redundancy (and roo= m for error) in all certificates seems like a bad tradeoff for local policy= that could be updated independently. --dkg _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Nov 17 22:32:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFCC3A10B4 for ; Tue, 17 Nov 2020 16:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=entrust.com header.b=DAHs4whG; dkim=pass (2048-bit key) header.d=entrust.com header.b=E+yHnv0L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96F2FnA2H6zl for ; Tue, 17 Nov 2020 16:13:41 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 4F1E53A10A0 for ; Tue, 17 Nov 2020 16:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=entrust.com; i=@entrust.com; q=dns/txt; s=esa1; t=1605658421; x=1637194421; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QdytjRHLmzrqTHflhZbE0GgHl78q/jK5wt7eWDH/4EI=; b=DAHs4whGmDSnN/gOqidNxUJbgecw0arfemKA7bBvePJOXgM/ECVDi35V lvym+//HxqUxf5+ItfqDV8RBfudRA2LmT+5M3CI6kSVjDt1ZVXO2LmO8l +VfQ9TZjBfZLv1bHIJYOzDAaNZNd5ewit/b7dAVugR0Akg0JtcVHjrFW6 c/yg08nCYWiE68HuWTsbJ52xUIpkf91wmW+pcQIIqnUZF9PLg3uHTivGX uUpITcLsT4RaduI2LTDftjBDSt6eeyH0DXgh4D617Rxb9gdIt6tyjZUL6 7a37Ks+RFZtanEAZYk1MDmrRH5SIerYnwSCNB0kyAtr/7/xKdDg9jxfxM Q==; IronPort-SDR: HTokVH7gJWjUFPtvMfBQkxOXyn7lUqHcElvAVAo+Pi8OYIo0eQeFdLFsawKXDSB59tVCHD/VYC x2TTeobEUPjA== X-IronPort-AV: E=Sophos;i="5.77,486,1596517200"; d="scan'208";a="23678552" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Nov 2020 18:13:40 -0600 Received: from PMSPEX03.corporate.datacard.com (192.168.211.50) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 17 Nov 2020 18:13:37 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (172.28.1.8) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 17 Nov 2020 18:13:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IUsI/9NcfvKt4T+nX21bgoSK7Kf5t5hpXGFpJi/It1TPjiemiVrjB++kPBgMGbPosJpdKRl23HMcb2lXTYTe0kqrtqTr4q9m7CJ7irmSkdvPqTM0VyHp4w8LD6R/Nmt1f9G5a3PvWvErFeOmoxzYp4QnDP2iSDl2ZqMRgptkFQP76bueqhpVh4d9lzayG23gc1fNt45KdEsceq1hW7ADvSNuIA9tpSELI+IGvvFxZ2+yOQ8l1avcOB8yR2CDn1B15ZhivGzu9oSZyHx/d1WA/GWM0+brTeQFBjvrVThMQLQLdy+IKdXCeeetJFlWKZUyXK65vBEJQ08x3RQ0o7vDdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ONx09vSwFOjU+gKbsMZU7ZoYmy+RleeAT/2XVuPeTFQ=; b=NuU+uuumrfcKUe2G38DKUrYrqu5PhlR5cnrF5dS3jLN3R/rmo788KXa4SaAILYyWnHelMlvZat4cZFPkpNHkV11pJNuTds+F6ZfUHuB9et4zXrB97hE4fcofdmtyDuRMbitdHTvRpIRW/63GLcTwpIivvBNTthNThlNWE7FwZ9yw9Qc65E6Ce0fJd7faZ/2ooPMjEbKLDXE7pn7cHgAT2gQQy79ze4g8lXj263v/3kLRqf2HNoajHu35HsRjcvmoDrQp+cDH9ZtpHAQwp7MePi9lneOqOzxQEQC+UQMo5nE/zjyvcLoVDfx+VxNj0KW/iNBKAdt483/7Cg+pPiR7Vg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrust.com; dmarc=pass action=none header.from=entrust.com; dkim=pass header.d=entrust.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrust.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ONx09vSwFOjU+gKbsMZU7ZoYmy+RleeAT/2XVuPeTFQ=; b=E+yHnv0LRZ7I+m2LboVY5/u/tXPY7DAqEOlaDT6qRxqMiMZ5lKtTj77Zq0odMTopexIb88y2nhW9Mo3H5UVGoWMj7Tm+NesZ8+DiC2gSfx4F0qxkBmhrLexZMXDFLSLkvRBcvVZFzLgSfLr1xL7XiKQWSQseV7iM5sRhBI160c972CXJCt1BOEn2fbtjpTiphh0GdHQ60dycKm9WYGfZDaEGmnyCjXkLKN6VhUIb57rY1vocsc+L58PaNYDCS1TBOTk87Xj9OmXVSGgXwCOOv50i4ZpeRKf9hy4TGR5vqAjZA7rKjMxuBc8JVanp+QnlzoHJPgJ/kHFg0BxU7W/cAg== Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB2667.namprd11.prod.outlook.com (2603:10b6:5:c1::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.28; Wed, 18 Nov 2020 00:13:34 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::3c6a:d17b:805e:dc6c%3]) with mapi id 15.20.3564.030; Wed, 18 Nov 2020 00:13:34 +0000 From: Mike Ounsworth To: Santosh Chokhani , 'LAMPS' Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvT6klegkjggODUa39kAl/kCtxanNAyEg Date: Wed, 18 Nov 2020 00:13:34 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <124f01d6bd3e$8a494d10$9edbe730$@gmail.com> In-Reply-To: <124f01d6bd3e$8a494d10$9edbe730$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=entrust.com; x-originating-ip: [204.124.81.16] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6258ea5c-b817-4db3-e885-08d88b56ca05 x-ms-traffictypediagnostic: DM6PR11MB2667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: c6v8bZgWGscLvDHBNY7oNB/WTnf6v3M2WjKdsggFCIqnQiZA8iYAlJqOJc/0dCPxRhpf/uwVQ+zk1KV/WbTdbRwnQP05TK0pQIgpzw4fReA/j3TPHhluvrpUofqS1tFBqxmje1P0hRxQpQ9UDoJ+goK9atE+3hDbX9H9R1zmo/OjcXMhMcvYlRDULrwE1T9HABLx3cp7KQo7R8LsuGgYhdMilbguqsQY53ZYjTyMDwjF2jwZPTZjHsF2RgAbgT9YH74TdN+JXzmj0gPaRmIEjSGBgiQGrB4GPX+rGvooxLWTxdHSlX880/XmDoRgC9q2ebRr2iDnIs0GO6IWTyDYoGhuMKEfp1W8gMKeoxOayrxqbMPSk3aSSokUoX1nXuZJLRuc1vf8wVntbZy32PoPRw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3915.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(396003)(39860400002)(346002)(6506007)(71200400001)(2906002)(478600001)(64756008)(9686003)(186003)(83380400001)(26005)(316002)(8936002)(8676002)(7696005)(33656002)(55016002)(66946007)(52536014)(53546011)(5660300002)(110136005)(66446008)(86362001)(966005)(66476007)(76116006)(4001150100001)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: YzB0tKOmyIPcOzlWW8td0kZTebadMMbkdqX6qEphrmMcIOtQu2MN1EqOCEyKMPNBMcrTNqqMxGe52UrxIYXjXH+8zDlVQj9efvPYcMM8+h4CUZ1c8OYN4tXanSLXzeyx3GeyNEXlGtcrIMfhDyJ63lXPwWUGwOHOl/uHI1JdbuvCopldzZwqlctXP3qOF6RYwjhHzxLaGrsTHPxXECjXy9LsE7m8CCAtjsoJ9gsiTDLnfy3vUlEMDohg3TlP8ko12PLMnQCLm36EXimLeblIga2RwpwvFf5FgAijmBq/YV4TcWCF5R6AyRphu3mSbwi10PXtfj5JEedXl+n/vNLY98JYL7FkuvSe40WIodL3RMtx/tQxhE7mKMk1gajTRjslLriZE67HiIzgKd8gqmM/5KuKco6n3cI0vNGot25ds68ejQASK3t82+uAPpFPZsOLdrrUH/jcSFrKBEjqYSyz5pwlqiS2UABL2KtpPXtP98pjqOJhdd2tK93dwQPRwJz7IHxNNEF1GvJoOisMT9mWehnXVRy5D1NUuLdJW3glaZdrVXeEqeIz20QM5KPwNZN5BIWkq2EKfNvzYoCaQcCaPeyA/TKhsMVmMF3CIA8g4uiDEVoi9p8sItGtlLLQC1u0ooNIhmApQQzrEaqk/T36KA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3915.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6258ea5c-b817-4db3-e885-08d88b56ca05 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2020 00:13:34.4998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4pMEVNYa7YeF96SK9k898Ijp1PooXlt3LDK6kyxTh33E1W0MuH5VHn/lVCk44wHU/g7rlzBDSvbENXhk8GEl4WrHcA6zxoQ0R5ZD868/M/g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2667 X-OriginatorOrg: entrust.com Archived-At: X-Mailman-Approved-At: Tue, 17 Nov 2020 22:32:25 -0800 Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 00:13:43 -0000 Hi Santosh.=20 I'm not talking about the delegated OCSP Responder cert (ie the thing signi= ng OCSP responses), but rather the TLS cert on the webserver sitting in fro= nt of the OCSP Responder. That means you could put an HTTPS URL in the OCSP= AIA. It means we wouldn't have the OCSP endpoint be HTTP when everything e= lse is HTTPS. --- Mike Ounsworth -----Original Message----- From: Spasm On Behalf Of Santosh Chokhani Sent: November 17, 2020 6:06 PM To: 'LAMPS' Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Mike, Recursion in OCSP check is avoided by simply asserting OCSP-nocheck in dele= gated OCSP Responder certificate. noRevAvail obviates revocation checking for attribute certificate. Neither fit a TLS Server, TLS Client or E-Mail client. It will all be a fu= nction of how relying party software behaves if either one works. I suppos= e asserting both is saying I hope RP gets one of the two in the context of = a certificate which is neither attribute certificate nor delegated OCSP Res= ponder certificate. I would like to review DKG I-D and I-D scope to figure out if I can provide= any helpful suggestion. -----Original Message----- From: Mike Ounsworth [mailto:Mike.Ounsworth@entrust.com] Sent: Tuesday, November 17, 2020 6:48 PM To: Santosh Chokhani ; 'LAMPS' Subject: RE: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension Unless I'm missing something, another concrete use-case for allowing id-ce-= noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow OCSP over= HTTPS (unless there's another way that I'm not aware of to break the recur= sive OCSP checks loop). Clients for this use case would be "anything web". --- Mike Ounsworth -----Original Message----- From: Spasm On Behalf Of Santosh Chokhani Sent: November 17, 2020 11:58 AM To: 'LAMPS' Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. DKG, This determination should be based on how client behaves when no revocation= information can be obtained. =20 As to OCSP client policy, clients can go to responder(s) that are locally c= onfigured (causing delays) and come back with no tangible information. The question boils down to do you want client to continue and without any w= arning or anomaly? If so, that should be indicated in the certificate and = not by omission of CRL DP and OCSP. Again, the client needs to process tha= t indication to mean all is well. I also do not see a need for both extensions. No-check might not work with= COTS because some existing clients may deal with it for OCSP responder del= egated certificate. =20 If this is a client you have control over, I would say you can make either = extension work. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmo= r Sent: Tuesday, November 17, 2020 12:36 PM To: Russ Housley ; LAMPS Subject: Re: [lamps] The id-ce-noRevAvail extension On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no=20 > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time=20 > needed to detect, report, and distribute revocation information. As a=20 > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation infor= mation available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also cr= eate an opportunity for confusion, because a single certificate can now cla= im an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to= have to check for? The only reason to push for (b) is if there is a legitimate case where a st= andard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP respond= er for a certificate is published in (and looked for by the relying party i= n) the *issuer's* intermdiate CA certificate, but is *not* expected to also= be published in the certificate itself, then we'd need (b) for the CA to b= e able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't kno= w about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the tw= o options for finding the OCSP responder location are (1) in the certificat= e itself whose status is being checked, or (2) "configured locally at the O= CSP client". If the only scenario anyone can produce is "configured locally at the OCSP = client," then presumably such a policy requires identifying *which* certifi= cates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to= match on a different set of certificates. Introducing redundancy (and roo= m for error) in all certificates seems like a bad tradeoff for local policy= that could be updated independently. --dkg _______________________________________________ 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 Wed Nov 18 04:12:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46D13A17F9 for ; Wed, 18 Nov 2020 04:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHBb3xJdsFmo for ; Wed, 18 Nov 2020 04:12:26 -0800 (PST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (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 E99963A17F8 for ; Wed, 18 Nov 2020 04:12:25 -0800 (PST) Received: by mail-pj1-f54.google.com with SMTP id ms7so405100pjb.4 for ; Wed, 18 Nov 2020 04:12:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FC+xNgpkUUCArxRTmPWVURnbARd0iecwJEW8wxZBDKM=; b=foWpejgjcC2w6IJrgRGhJTWmUL3Dev+jXuLXsHRoZD+KHIBTICrV84OHCh3phkLZYL zEJFGZqvEvGmk0u4VMpFwHFojCOkKHYr5GoFk61AjZTn57Neiajc1XoP411Wq8dgkLi3 UZfNdm7KGZLE1NkXIOnCfkniymwAydUYvlD96iFSBiL7TyZDh5TUuqRlk5GRb65VqiBu /nmrkKKgEJh8vnMGTDFbMjUpMmmcXVXsHc+SqajaWhdkVQAPR4yCFcFjEROBfmEWr/yC 3Ts5TCW+/EZTYEpfQDw80dc37qx+B/GS3boNrmqwpWUZLqrMOepA3NPKZrhF0P+bWTT6 jAoQ== X-Gm-Message-State: AOAM531dSmDpTPoAHzz7K2KJq2tMJLFBFBjfvGBBDehflnb+AFDoCW3H zpnIbJp/K0mA0Mu83fUd2ODCBTWAYC0= X-Google-Smtp-Source: ABdhPJya6GHPvqKOzc206JkDb2ZiOz+Yf9xaAnYmoYdUAcFlesQ3Az4S2AK2Yeweyghd3G9IeQEhRg== X-Received: by 2002:a17:90b:a54:: with SMTP id gw20mr3958378pjb.178.1605701544981; Wed, 18 Nov 2020 04:12:24 -0800 (PST) Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com. [209.85.215.173]) by smtp.gmail.com with ESMTPSA id cv4sm2364107pjb.1.2020.11.18.04.12.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 04:12:24 -0800 (PST) Received: by mail-pg1-f173.google.com with SMTP id 81so1084133pgf.0 for ; Wed, 18 Nov 2020 04:12:24 -0800 (PST) X-Received: by 2002:a65:50c5:: with SMTP id s5mr7767144pgp.399.1605701544601; Wed, 18 Nov 2020 04:12:24 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: From: Ryan Sleevi Date: Wed, 18 Nov 2020 07:12:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Mike Ounsworth Cc: LAMPS , Santosh Chokhani Content-Type: multipart/alternative; boundary="0000000000002e706105b4608687" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 12:12:28 -0000 --0000000000002e706105b4608687 Content-Type: text/plain; charset="UTF-8" I think you might be missing something, because as I explained, and as DKG mentioned, the omission of such information within a certificate is sufficient. If you believe there is a necessity for an extension, you need to describe a processing model of RFC 5280 that behaves differently. This should be a hopefully easy exercise. On Wed, Nov 18, 2020 at 1:32 AM Mike Ounsworth wrote: > Unless I'm missing something, another concrete use-case for allowing > id-ce-noRevAvail and id-pkix-ocsp-nocheck in EE certs would be to allow > OCSP over HTTPS (unless there's another way that I'm not aware of to break > the recursive OCSP checks loop). Clients for this use case would be > "anything web". > > --- > Mike Ounsworth > > -----Original Message----- > From: Spasm On Behalf Of Santosh Chokhani > Sent: November 17, 2020 11:58 AM > To: 'LAMPS' > Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > > DKG, > > This determination should be based on how client behaves when no > revocation information can be obtained. > > As to OCSP client policy, clients can go to responder(s) that are locally > configured (causing delays) and come back with no tangible information. > > The question boils down to do you want client to continue and without any > warning or anomaly? If so, that should be indicated in the certificate and > not by omission of CRL DP and OCSP. Again, the client needs to process > that indication to mean all is well. > > I also do not see a need for both extensions. No-check might not work > with COTS because some existing clients may deal with it for OCSP responder > delegated certificate. > > If this is a client you have control over, I would say you can make either > extension work. > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn > Gillmor > Sent: Tuesday, November 17, 2020 12:36 PM > To: Russ Housley ; LAMPS > Subject: Re: [lamps] The id-ce-noRevAvail extension > > On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > > Remember that this is part of the LAMPS WG charter: > > > > 1. Specify the use of short-lived X.509 certificates for which no > > revocation information is made available by the Certification Authority. > > Short-lived certificates have a lifespan that is shorter than the time > > needed to detect, report, and distribute revocation information. As a > > result, revoking short-lived certificates is unnecessary and pointless. > > I agree that this is part of the charter. > > I see two options for signalling that a certificate has no revocation > information available: > > (a) omit any mention of an OCSP responder or CRL location in the > certificate itself. > > or > > (b) explicitly specify the extensions id-ce-noRevAvail and > id-pkix-ocsp-nocheck > > (a) seems like it has the advantage of being simpler. (b) seems to also > create an opportunity for confusion, because a single certificate can now > claim an OCSP responder, a CRL location, *and* specify these locations. > What would that even mean? Is this a new error case for implementations > to have to check for? > > The only reason to push for (b) is if there is a legitimate case where a > standard policy mechanism needs to be *overridden* for a given certificate. > For example, if there is a situation where the CRL location or OCSP > responder for a certificate is published in (and looked for by the relying > party in) the *issuer's* intermdiate CA certificate, but is *not* expected > to also be published in the certificate itself, then we'd need (b) for the > CA to be able to override the default location. > > Does such a standard policy exist? I'm not an X.509 expert, so i don't > know about it. If it does, a pointer to it would clarify the need for (b). > > wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the > two options for finding the OCSP responder location are (1) in the > certificate itself whose status is being checked, or (2) "configured > locally at the OCSP client". > > If the only scenario anyone can produce is "configured locally at the OCSP > client," then presumably such a policy requires identifying *which* > certificates to apply such an OCSP check to. > > It seems like the solution for that use case is that local configuration > to match on a different set of certificates. Introducing redundancy (and > room for error) in all certificates seems like a bad tradeoff for local > policy that could be updated independently. > > --dkg > > _______________________________________________ > 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 > --0000000000002e706105b4608687 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you might be missing something, because as I expl= ained, and as DKG mentioned, the omission of such information within a cert= ificate is sufficient.

I= f you believe there is a necessity for an extension, you need to describe a= processing model of RFC 5280 that behaves differently. This should be a ho= pefully easy exercise.

On Wed, Nov 18, 2020 at 1:32 AM Mike Ounsworth &= lt;Mike.Ounsworth=3D40entru= st.com@dmarc.ietf.org> wrote:
spasm-bounces@ietf.org> On Behalf Of Santosh Chokhani
Sent: November 17, 2020 11:58 AM
To: 'LAMPS' <spasm@ietf.org>
Subject: [EXTERNAL]Re: [lamps] The id-ce-noRevAvail extension

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe.

DKG,

This determination should be based on how client behaves when no revocation= information can be obtained.=C2=A0

As to OCSP client policy, clients can go to responder(s) that are locally c= onfigured (causing delays) and come back with no tangible information.

The question boils down to do you want client to continue and without any w= arning or anomaly?=C2=A0 If so, that should be indicated in the certificate= and not by omission of CRL DP and OCSP.=C2=A0 Again, the client needs to p= rocess that indication to mean all is well.

I also do not see a need for both extensions.=C2=A0 No-check might not work= with COTS because some existing clients may deal with it for OCSP responde= r delegated certificate.=C2=A0

If this is a client you have control over, I would say you can make either = extension work.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] The id-ce-noRevAvail extension

On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote:
> Remember that this is part of the LAMPS WG charter:
>
> 1. Specify the use of short-lived X.509 certificates for which no
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information. As a =
> result, revoking short-lived certificates is unnecessary and pointless= .

I agree that this is part of the charter.

I see two options for signalling that a certificate has no revocation infor= mation available:

=C2=A0(a) omit any mention of an OCSP responder or CRL location in the
=C2=A0 =C2=A0 =C2=A0certificate itself.

or

=C2=A0(b) explicitly specify the extensions id-ce-noRevAvail and
=C2=A0 =C2=A0 =C2=A0id-pkix-ocsp-nocheck

(a) seems like it has the advantage of being simpler.=C2=A0 (b) seems to al= so create an opportunity for confusion, because a single certificate can no= w claim an OCSP responder, a CRL location, *and* specify these locations. What would that even mean?=C2=A0 Is this a new error case for implementatio= ns to have to check for?

The only reason to push for (b) is if there is a legitimate case where a st= andard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP respond= er for a certificate is published in (and looked for by the relying party i= n) the *issuer's* intermdiate CA certificate, but is *not* expected to = also be published in the certificate itself, then we'd need (b) for the= CA to be able to override the default location.

Does such a standard policy exist?=C2=A0 I'm not an X.509 expert, so i = don't know about it.=C2=A0 If it does, a pointer to it would clarify th= e need for (b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#secti= on-3 says that the two options for finding the OCSP responder location = are (1) in the certificate itself whose status is being checked, or (2) &qu= ot;configured locally at the OCSP client".

If the only scenario anyone can produce is "configured locally at the = OCSP client," then presumably such a policy requires identifying *whic= h* certificates to apply such an OCSP check to.

It seems like the solution for that use case is that local configuration to= match on a different set of certificates.=C2=A0 Introducing redundancy (an= d room for error) in all certificates seems like a bad tradeoff for local p= olicy that could be updated independently.

=C2=A0 =C2=A0 =C2=A0 --dkg

_______________________________________________
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
--0000000000002e706105b4608687-- From nobody Wed Nov 18 04:34:25 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4CB3A184D for ; Wed, 18 Nov 2020 04:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcmTKN9ddV8z for ; Wed, 18 Nov 2020 04:34:22 -0800 (PST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 1E7483A184C for ; Wed, 18 Nov 2020 04:34:22 -0800 (PST) Received: by mail-pg1-f170.google.com with SMTP id f18so1095684pgi.8 for ; Wed, 18 Nov 2020 04:34:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b85EoEOUVmpj1kXvJj6Hy4gzFZ8jwIBteG5QnLV1Z/E=; b=I4yEQlGtUoMf/obbjrob+4qY59M2RjSc07QFvdO7TJ59a+zYh2AG09Nw0t+0zOKPHL KNVMmyPnVp224bupuS9Brcvd9QjDuC+T+0EuB8k6lJWMTp3Gsm001AxNrfksH+uMpOss GH2j0N3R01KOE93O4cRQdPYeRz1V0tOp2Ci8Pp0ZjzxpK7K77eIptYughxaZ9sMVQ1lr GIVflCHGrX51ZH3OpfJ2tOuOieDamZ12qh0sVD69hRb1sAShZb+3ySFoXFuqb47gK4g4 LfsmiFCsvBLCrqAd4RVmcSSLT9POGs8cdfW05hAqiihYMed9neCGqTOfi08GCvufzvl3 C3jA== X-Gm-Message-State: AOAM532qiblew9E22IXAiOWMiLAiC6R+SJzwbeiNxvTVCNB5IzWlU2yd WvA5j9SSjhp00xYrlnHEuXPVcKnfQZU= X-Google-Smtp-Source: ABdhPJyRuwtTMcSqJ1Ok20iGRXAahTsbUbbHCZnR7CieUXUxLnmUGwm5heEUQ3YtVpwrg0D2KNfVUQ== X-Received: by 2002:a63:2d86:: with SMTP id t128mr8196478pgt.5.1605702861128; Wed, 18 Nov 2020 04:34:21 -0800 (PST) Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com. [209.85.214.170]) by smtp.gmail.com with ESMTPSA id gg19sm2487819pjb.21.2020.11.18.04.34.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 04:34:20 -0800 (PST) Received: by mail-pl1-f170.google.com with SMTP id l11so922983plt.1 for ; Wed, 18 Nov 2020 04:34:20 -0800 (PST) X-Received: by 2002:a17:90b:3506:: with SMTP id ls6mr3688324pjb.202.1605702860506; Wed, 18 Nov 2020 04:34:20 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: <102d01d6bd0b$3a880150$af9803f0$@gmail.com> From: Ryan Sleevi Date: Wed, 18 Nov 2020 07:33:46 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Santosh Chokhani Cc: LAMPS Content-Type: multipart/alternative; boundary="0000000000009d8c3705b460d42b" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 12:34:24 -0000 --0000000000009d8c3705b460d42b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Santosh, This doesn=E2=80=99t really explain the necessity for an extension, and I= =E2=80=99m hoping that if you believe it necessary, you can describe a concrete processing model where it does, with reference to RFC 5280. There are several critical assumptions here that you haven=E2=80=99t actual= ly elaborated on: 1. That a client will have a different output based on the presence of this extension than without. Can you describe, tangibly, what those outputs are, and how that fits with today=E2=80=99s RFC 5280 processing model, since you clearly make reference= to this possibility? 2. That clients, which are updated to support whatever semantics #1 proposes, have no other way of achieving this result. The problem here is that in order for an extension to be useful, it needs to have new semantics (#1), which means the client must update to support that extension. Since we have to assume the client can update, it doesn=E2= =80=99t make any sense to suggest this is the only possible solution. 3. That this is a matter for CA expression, and not local policy. >From what you describe, there=E2=80=99s a clear desire that client behavior= should change (#1) based on some direction of the CA (#2). However, honestly and fully answering #2 requires us to also ask: is this something that the CA should be defining in the first place, or is this really a matter for local policy? To understand this, consider if we assume that there is some (yet-undefined) processing model associated to the semantics of putting it into an extension, and all clients are updated to these semantics. This extension is now present in a CA certificate valid for 30 years. Should the client trust that CA or, since it expects revocation details, reject it? I should hope the answer is =E2=80=9Creject=E2=80=9D. What about if this was = an EE cert, valid for 1y? Again, I would hope the answer is reject. What this means is that, even assuming the extension and semantics, there= =E2=80=99s some local policy involved which cannot simply blindly trust the CA and go =E2=80=9Cwell, they said no revocation would ever be available, and that=E2= =80=99s fine by me,=E2=80=9D because to do so would be laughably insecure. So whether or no= t a CA is permitted to definitively not provide revocation details then has to consider local policy about when that is acceptable, which means that the CA=E2=80=99s explicit expression doesn=E2=80=99t override or replace local = policy. Since local policy is now involved (answering #3), it means we have more options to solve (#2), including that clients simply update to handle omitted revocation details to whatever preferred semantics for #1 . So no, I don=E2=80=99t see the necessity of an explicit extension here. On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani < santosh.chokhani@gmail.com> wrote: > DKG, > > This determination should be based on how client behaves when no revocati= on > information can be obtained. > > As to OCSP client policy, clients can go to responder(s) that are locally > configured (causing delays) and come back with no tangible information. > > The question boils down to do you want client to continue and without any > warning or anomaly? If so, that should be indicated in the certificate a= nd > not by omission of CRL DP and OCSP. Again, the client needs to process > that > indication to mean all is well. > > I also do not see a need for both extensions. No-check might not work wi= th > COTS because some existing clients may deal with it for OCSP responder > delegated certificate. > > If this is a client you have control over, I would say you can make eithe= r > extension work. > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn > Gillmor > Sent: Tuesday, November 17, 2020 12:36 PM > To: Russ Housley ; LAMPS > Subject: Re: [lamps] The id-ce-noRevAvail extension > > On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > > Remember that this is part of the LAMPS WG charter: > > > > 1. Specify the use of short-lived X.509 certificates for which no > > revocation information is made available by the Certification Authority= . > > Short-lived certificates have a lifespan that is shorter than the time > > needed to detect, report, and distribute revocation information. As a > > result, revoking short-lived certificates is unnecessary and pointless. > > I agree that this is part of the charter. > > I see two options for signalling that a certificate has no revocation > information available: > > (a) omit any mention of an OCSP responder or CRL location in the > certificate itself. > > or > > (b) explicitly specify the extensions id-ce-noRevAvail and > id-pkix-ocsp-nocheck > > (a) seems like it has the advantage of being simpler. (b) seems to also > create an opportunity for confusion, because a single certificate can now > claim an OCSP responder, a CRL location, *and* specify these locations. > What would that even mean? Is this a new error case for implementations = to > have to check for? > > The only reason to push for (b) is if there is a legitimate case where a > standard policy mechanism needs to be *overridden* for a given certificat= e. > For example, if there is a situation where the CRL location or OCSP > responder for a certificate is published in (and looked for by the relyin= g > party in) the *issuer's* intermdiate CA certificate, but is *not* expecte= d > to also be published in the certificate itself, then we'd need (b) for th= e > CA to be able to override the default location. > > Does such a standard policy exist? I'm not an X.509 expert, so i don't > know > about it. If it does, a pointer to it would clarify the need for (b). > > wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the > two > options for finding the OCSP responder location are (1) in the certificat= e > itself whose status is being checked, or (2) "configured locally at the > OCSP > client". > > If the only scenario anyone can produce is "configured locally at the OCS= P > client," then presumably such a policy requires identifying *which* > certificates to apply such an OCSP check to. > > It seems like the solution for that use case is that local configuration = to > match on a different set of certificates. Introducing redundancy (and ro= om > for error) in all certificates seems like a bad tradeoff for local policy > that could be updated independently. > > --dkg > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000009d8c3705b460d42b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Santosh,

This doesn=E2=80=99t really explain the necessity for an extension, and = I=E2=80=99m hoping that if you believe it necessary, you can describe a con= crete processing model where it does, with reference to RFC 5280.

There are several critical assump= tions here that you haven=E2=80=99t actually elaborated on:

1. That a client will have a differen= t output based on the presence of this extension than without.

Can you describe, tangibly, what tho= se outputs are, and how that fits with today=E2=80=99s RFC 5280 processing = model, since you clearly make reference to this possibility?

2. That clients, which are updated to= support whatever semantics #1 proposes, have no other way of achieving thi= s result.

The problem he= re is that in order for an extension to be useful, it needs to have new sem= antics (#1), which means the client must update to support that extension. = Since we have to assume the client can update, it doesn=E2=80=99t make any = sense to suggest this is the only possible solution.

3. That this is a matter for CA expression, an= d not local policy.

From= what you describe, there=E2=80=99s a clear desire that client behavior sho= uld change (#1) based on some direction of the CA (#2). However, honestly a= nd fully answering #2 requires us to also ask: is this something that the C= A should be defining in the first place, or is this really a matter for loc= al policy?

To understand= this, consider if we assume that there is some (yet-undefined) processing = model associated to the semantics of putting it into an extension, and all = clients are updated to these semantics. This extension is now present in a = CA certificate valid for 30 years. Should the client trust that CA or, sinc= e it expects revocation details, reject it? I should hope the answer is =E2= =80=9Creject=E2=80=9D. What about if this was an EE cert, valid for 1y? Aga= in, I would hope the answer is reject.

What this means is that, even assuming the extension and sem= antics, there=E2=80=99s some local policy involved which cannot simply blin= dly trust the CA and go =E2=80=9Cwell, they said no revocation would ever b= e available, and that=E2=80=99s fine by me,=E2=80=9D because to do so would= be laughably insecure. So whether or not a CA is permitted to definitively= not provide revocation details then has to consider local policy about whe= n that is acceptable, which means that the CA=E2=80=99s explicit expression= doesn=E2=80=99t override or replace local policy. Since local policy is no= w involved (answering #3), it means we have more options to solve (#2), inc= luding that clients simply update to handle omitted revocation details to w= hatever preferred semantics for #1 .

So no, I don=E2=80=99t see the necessity of an explicit extens= ion here.

On Tue, Nov 17= , 2020 at 12:58 PM Santosh Chokhani <santosh.chokhani@gmail.com> wrote:
DKG,

This determination should be based on how client behaves when no revocation=
information can be obtained.=C2=A0

As to OCSP client policy, clients can go to responder(s) that are locally configured (causing delays) and come back with no tangible information.

The question boils down to do you want client to continue and without any warning or anomaly?=C2=A0 If so, that should be indicated in the certificat= e and
not by omission of CRL DP and OCSP.=C2=A0 Again, the client needs to proces= s that
indication to mean all is well.

I also do not see a need for both extensions.=C2=A0 No-check might not work= with
COTS because some existing clients may deal with it for OCSP responder
delegated certificate.=C2=A0

If this is a client you have control over, I would say you can make either<= br> extension work.

-----Original Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] The id-ce-noRevAvail extension

On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote:
> Remember that this is part of the LAMPS WG charter:
>
> 1. Specify the use of short-lived X.509 certificates for which no
> revocation information is made available by the Certification Authorit= y.
> Short-lived certificates have a lifespan that is shorter than the time=
> needed to detect, report, and distribute revocation information. As a =
> result, revoking short-lived certificates is unnecessary and pointless= .

I agree that this is part of the charter.

I see two options for signalling that a certificate has no revocation
information available:

=C2=A0(a) omit any mention of an OCSP responder or CRL location in the
=C2=A0 =C2=A0 =C2=A0certificate itself.

or

=C2=A0(b) explicitly specify the extensions id-ce-noRevAvail and
=C2=A0 =C2=A0 =C2=A0id-pkix-ocsp-nocheck

(a) seems like it has the advantage of being simpler.=C2=A0 (b) seems to al= so
create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations.
What would that even mean?=C2=A0 Is this a new error case for implementatio= ns to
have to check for?

The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate.=
For example, if there is a situation where the CRL location or OCSP
responder for a certificate is published in (and looked for by the relying<= br> party in) the *issuer's* intermdiate CA certificate, but is *not* expec= ted
to also be published in the certificate itself, then we'd need (b) for = the
CA to be able to override the default location.

Does such a standard policy exist?=C2=A0 I'm not an X.509 expert, so i = don't know
about it.=C2=A0 If it does, a pointer to it would clarify the need for (b).=

wrt to OCSP, https://tools.ietf.org/html/rfc6960#secti= on-3 says that the two
options for finding the OCSP responder location are (1) in the certificate<= br> itself whose status is being checked, or (2) "configured locally at th= e OCSP
client".

If the only scenario anyone can produce is "configured locally at the = OCSP
client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to.

It seems like the solution for that use case is that local configuration to=
match on a different set of certificates.=C2=A0 Introducing redundancy (and= room
for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently.

=C2=A0 =C2=A0 =C2=A0 --dkg

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000009d8c3705b460d42b-- From nobody Wed Nov 18 05:09:07 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F933A1884 for ; Wed, 18 Nov 2020 05:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VUo4lL2sPgvT for ; Wed, 18 Nov 2020 05:09:03 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 748B23A17E7 for ; Wed, 18 Nov 2020 05:09:03 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id n132so1677478qke.1 for ; Wed, 18 Nov 2020 05:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=znNN1Y2S3w1sTcMitxG1bh2DvWSfTB2vY8NXFGYaeGk=; b=rAwCqXwkyjx3E/5bNFO1oWMP4xPM7qNr+wq1HE4Kty2K7qqW01V0C6ezhWtSHNmOZ7 3i0Q3qdb3SvF75h5giKRP1ch6EtHD839UZYRyA5O4RZ0p3/+0KoJz2WkhyT/voDZax8C sU8Ozbo4IyDUijzYEZEf3LIwddM7nfGPjvHZqF6yw6Ub3mCLCubQkM6MsQh8HtKKHSK9 4paHCaMmE8tV6hUxFqK6yIm7ONOxtBbKZHS/4zFJhQp+PnS5pS3uoQ9NVcRXIcq+lsOM JgAnn4dAk85MY7KruUAxL2p49qv/qOAREYojx2QOP8mlsmUAeoCCbgux3znSGOefJgdB vW9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=znNN1Y2S3w1sTcMitxG1bh2DvWSfTB2vY8NXFGYaeGk=; b=fz5Fcq/6mPyklKGIy4DKkxCH5cZAj8vl1lFJocUmqnzhxmCnjhNdejSKrMlWTE+PTk 454oO90qwA1Uitne6L8eu+D8IMW20Dln0DUhByzx+ccx2F8pHyQZKpr7+BzQMkv/TnMH K7ALqe5UHyZW0WMEjrNqUj0fXsHAYjkYGGJ+Nz+/xaMJiKRE6wUhJVtamcc5loeWpmPd j2+x5GJyn2F+EewofXd+OOpmtq34P1fcBPhe6UFoUdSazVrU5cM/vRelLeSsupws164k vWkeBztuWPPtL2MGEC/yVP8VeFHyPhGF8Sgw1lArzLsuakBktT2FDDhMd+ctWqbCOy7D OcYw== X-Gm-Message-State: AOAM530wjB8tlKAthaP8OOPKOl7ZBZNppfL8/hYolDy06C/0L1FMLqBi oRcEPz6LAB/jZ72VOTxJog18nQ+SMFg= X-Google-Smtp-Source: ABdhPJxYnrSEt4L7uHyfgjsLnHkGO2u+8NBCtGx6nUtDW0yvDbJxwmq9CXGHPzwZhH+XacGpprPb2w== X-Received: by 2002:a37:a3c4:: with SMTP id m187mr4358432qke.119.1605704942219; Wed, 18 Nov 2020 05:09:02 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id w192sm16299790qkb.17.2020.11.18.05.09.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 05:09:01 -0800 (PST) From: "Santosh Chokhani" To: "'LAMPS'" References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: Date: Wed, 18 Nov 2020 08:09:00 -0500 Message-ID: <004b01d6bdab$fbac2af0$f30480d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01D6BD82.12D845D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEwj93EDQf+67rRWWSqilgJXpnKwAJ6Ny4/AP3sFRMB+BZSggHDnm7QAg4XNZ0C7X263wGuXXnVAcI99H8C52Ev9QGvTaHfqniBFYA= Content-Language: en-us Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 13:09:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004C_01D6BD82.12D845D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ryan, It all depends on what the client does. Clearly OCSP RFC authors thought it useful to indicate this. They could have used your rationale. As I mentioned it all depends on if you are in control of the client consuming these certificates. If you are talking about all the X.509 enabled clients out there today, then you are right, the behavior will be varied as clients are and we do not clear. If you want to do something for a client you design for this class of certificates, I would recommend parking on OCSP-nocheck since its description in RFC 6960 is closer to what you are saying. From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com] Sent: Wednesday, November 18, 2020 7:34 AM To: Santosh Chokhani Cc: LAMPS Subject: Re: [lamps] The id-ce-noRevAvail extension Santosh, This doesn't really explain the necessity for an extension, and I'm hoping that if you believe it necessary, you can describe a concrete processing model where it does, with reference to RFC 5280. There are several critical assumptions here that you haven't actually elaborated on: 1. That a client will have a different output based on the presence of this extension than without. Can you describe, tangibly, what those outputs are, and how that fits with today's RFC 5280 processing model, since you clearly make reference to this possibility? 2. That clients, which are updated to support whatever semantics #1 proposes, have no other way of achieving this result. The problem here is that in order for an extension to be useful, it needs to have new semantics (#1), which means the client must update to support that extension. Since we have to assume the client can update, it doesn't make any sense to suggest this is the only possible solution. 3. That this is a matter for CA expression, and not local policy. >From what you describe, there's a clear desire that client behavior should change (#1) based on some direction of the CA (#2). However, honestly and fully answering #2 requires us to also ask: is this something that the CA should be defining in the first place, or is this really a matter for local policy? To understand this, consider if we assume that there is some (yet-undefined) processing model associated to the semantics of putting it into an extension, and all clients are updated to these semantics. This extension is now present in a CA certificate valid for 30 years. Should the client trust that CA or, since it expects revocation details, reject it? I should hope the answer is "reject". What about if this was an EE cert, valid for 1y? Again, I would hope the answer is reject. What this means is that, even assuming the extension and semantics, there's some local policy involved which cannot simply blindly trust the CA and go "well, they said no revocation would ever be available, and that's fine by me," because to do so would be laughably insecure. So whether or not a CA is permitted to definitively not provide revocation details then has to consider local policy about when that is acceptable, which means that the CA's explicit expression doesn't override or replace local policy. Since local policy is now involved (answering #3), it means we have more options to solve (#2), including that clients simply update to handle omitted revocation details to whatever preferred semantics for #1 . So no, I don't see the necessity of an explicit extension here. On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani > wrote: DKG, This determination should be based on how client behaves when no revocation information can be obtained. As to OCSP client policy, clients can go to responder(s) that are locally configured (causing delays) and come back with no tangible information. The question boils down to do you want client to continue and without any warning or anomaly? If so, that should be indicated in the certificate and not by omission of CRL DP and OCSP. Again, the client needs to process that indication to mean all is well. I also do not see a need for both extensions. No-check might not work with COTS because some existing clients may deal with it for OCSP responder delegated certificate. If this is a client you have control over, I would say you can make either extension work. -----Original Message----- From: Spasm [mailto:spasm-bounces@ietf.org ] On Behalf Of Daniel Kahn Gillmor Sent: Tuesday, November 17, 2020 12:36 PM To: Russ Housley >; LAMPS > Subject: Re: [lamps] The id-ce-noRevAvail extension On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > Remember that this is part of the LAMPS WG charter: > > 1. Specify the use of short-lived X.509 certificates for which no > revocation information is made available by the Certification Authority. > Short-lived certificates have a lifespan that is shorter than the time > needed to detect, report, and distribute revocation information. As a > result, revoking short-lived certificates is unnecessary and pointless. I agree that this is part of the charter. I see two options for signalling that a certificate has no revocation information available: (a) omit any mention of an OCSP responder or CRL location in the certificate itself. or (b) explicitly specify the extensions id-ce-noRevAvail and id-pkix-ocsp-nocheck (a) seems like it has the advantage of being simpler. (b) seems to also create an opportunity for confusion, because a single certificate can now claim an OCSP responder, a CRL location, *and* specify these locations. What would that even mean? Is this a new error case for implementations to have to check for? The only reason to push for (b) is if there is a legitimate case where a standard policy mechanism needs to be *overridden* for a given certificate. For example, if there is a situation where the CRL location or OCSP responder for a certificate is published in (and looked for by the relying party in) the *issuer's* intermdiate CA certificate, but is *not* expected to also be published in the certificate itself, then we'd need (b) for the CA to be able to override the default location. Does such a standard policy exist? I'm not an X.509 expert, so i don't know about it. If it does, a pointer to it would clarify the need for (b). wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the two options for finding the OCSP responder location are (1) in the certificate itself whose status is being checked, or (2) "configured locally at the OCSP client". If the only scenario anyone can produce is "configured locally at the OCSP client," then presumably such a policy requires identifying *which* certificates to apply such an OCSP check to. It seems like the solution for that use case is that local configuration to match on a different set of certificates. Introducing redundancy (and room for error) in all certificates seems like a bad tradeoff for local policy that could be updated independently. --dkg _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm ------=_NextPart_000_004C_01D6BD82.12D845D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ryan,

 

It all depends on what the client does.  Clearly OCSP RFC authors = thought it useful to indicate this.  They could have used your = rationale.

 

As I mentioned it all depends on if you are in control of the client = consuming these certificates.

 

If you are talking about all the X.509 enabled clients out there today, = then you are right, the behavior will be varied as clients are and we do = not clear.

 

If you want to do something for a client you design for this class of = certificates, I would recommend parking on OCSP-nocheck since its = description in RFC 6960 is closer to what you are = saying.

 

From:<= /b> = Ryan Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Wednesday, = November 18, 2020 7:34 AM
To: Santosh Chokhani = <santosh.chokhani@gmail.com>
Cc: LAMPS = <spasm@ietf.org>
Subject: Re: [lamps] The = id-ce-noRevAvail extension

 

Santosh,

 

This doesn’t really explain the necessity for an = extension, and I’m hoping that if you believe it necessary, you = can describe a concrete processing model where it does, with reference = to RFC 5280.

 

There are several critical assumptions here that you = haven’t actually elaborated on:

 

1. That a client will have a different output based on = the presence of this extension than without.

 

Can you describe, tangibly, what those outputs are, = and how that fits with today’s RFC 5280 processing model, since = you clearly make reference to this = possibility?

 

2. That clients, which are updated to support whatever = semantics #1 proposes, have no other way of achieving this = result.

 

The problem here is that in order for an extension to = be useful, it needs to have new semantics (#1), which means the client = must update to support that extension. Since we have to assume the = client can update, it doesn’t make any sense to suggest this is = the only possible solution.

 

3. That this is a matter for CA expression, and not = local policy.

 

From what you describe, there’s a clear desire = that client behavior should change (#1) based on some direction of the = CA (#2). However, honestly and fully answering #2 requires us to also = ask: is this something that the CA should be defining in the first = place, or is this really a matter for local = policy?

 

To understand this, consider if we assume that there = is some (yet-undefined) processing model associated to the semantics of = putting it into an extension, and all clients are updated to these = semantics. This extension is now present in a CA certificate valid for = 30 years. Should the client trust that CA or, since it expects = revocation details, reject it? I should hope the answer is = “reject”. What about if this was an EE cert, valid for 1y? = Again, I would hope the answer is reject.

 

What this means is that, even assuming the extension = and semantics, there’s some local policy involved which cannot = simply blindly trust the CA and go “well, they said no revocation = would ever be available, and that’s fine by me,” because to = do so would be laughably insecure. So whether or not a CA is permitted = to definitively not provide revocation details then has to consider = local policy about when that is acceptable, which means that the = CA’s explicit expression doesn’t override or replace local = policy. Since local policy is now involved (answering #3), it means we = have more options to solve (#2), including that clients simply update to = handle omitted revocation details to whatever preferred semantics for #1 = .

 

So no, I don’t see the necessity of an explicit = extension here.

 

On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani = <santosh.chokhani@gmail.com= > wrote:

DKG,

This determination should be based on how = client behaves when no revocation
information can be obtained.  =

As to OCSP client policy, clients can go to responder(s) that = are locally
configured (causing delays) and come back with no = tangible information.

The question boils down to do you want = client to continue and without any
warning or anomaly?  If so, = that should be indicated in the certificate and
not by omission of = CRL DP and OCSP.  Again, the client needs to process = that
indication to mean all is well.

I also do not see a need = for both extensions.  No-check might not work with
COTS because = some existing clients may deal with it for OCSP responder
delegated = certificate. 

If this is a client you have control over, I = would say you can make either
extension work.

-----Original = Message-----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn = Gillmor
Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley = <housley@vigilsec.com>; LAMPS <spasm@ietf.org>
Subject: Re: [lamps] The = id-ce-noRevAvail extension

On Tue 2020-11-17 03:25:08 -0500, Russ = Housley wrote:
> Remember that this is part of the LAMPS WG = charter:
>
> 1. Specify the use of short-lived X.509 = certificates for which no
> revocation information is made = available by the Certification Authority.
> Short-lived = certificates have a lifespan that is shorter than the time
> = needed to detect, report, and distribute revocation information. As a =
> result, revoking short-lived certificates is unnecessary and = pointless.

I agree that this is part of the charter.

I see = two options for signalling that a certificate has no = revocation
information available:

 (a) omit any mention = of an OCSP responder or CRL location in the
    =  certificate itself.

or

 (b) explicitly specify = the extensions id-ce-noRevAvail and
    =  id-pkix-ocsp-nocheck

(a) seems like it has the advantage of = being simpler.  (b) seems to also
create an opportunity for = confusion, because a single certificate can now
claim an OCSP = responder, a CRL location, *and* specify these locations.
What would = that even mean?  Is this a new error case for implementations = to
have to check for?

The only reason to push for (b) is if = there is a legitimate case where a
standard policy mechanism needs to = be *overridden* for a given certificate.
For example, if there is a = situation where the CRL location or OCSP
responder for a certificate = is published in (and looked for by the relying
party in) the = *issuer's* intermdiate CA certificate, but is *not* expected
to also = be published in the certificate itself, then we'd need (b) for the
CA = to be able to override the default location.

Does such a standard = policy exist?  I'm not an X.509 expert, so i don't know
about = it.  If it does, a pointer to it would clarify the need for = (b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says = that the two
options for finding the OCSP responder location are (1) = in the certificate
itself whose status is being checked, or (2) = "configured locally at the OCSP
client".

If the only = scenario anyone can produce is "configured locally at the = OCSP
client," then presumably such a policy requires identifying = *which*
certificates to apply such an OCSP check to.

It seems = like the solution for that use case is that local configuration = to
match on a different set of certificates.  Introducing = redundancy (and room
for error) in all certificates seems like a bad = tradeoff for local policy
that could be updated = independently.

      = --dkg

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

------=_NextPart_000_004C_01D6BD82.12D845D0-- From nobody Wed Nov 18 05:50:02 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07F43A03EC for ; Wed, 18 Nov 2020 05:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyv_phIP2NnX for ; Wed, 18 Nov 2020 05:49:58 -0800 (PST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B39C3A03AA for ; Wed, 18 Nov 2020 05:49:58 -0800 (PST) Received: by mail-pg1-f182.google.com with SMTP id q34so1219760pgb.11 for ; Wed, 18 Nov 2020 05:49:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NYjn0VNMEj+2XZEsieZStUZM8LSnrD+6RryOiCSB08E=; b=GFd7bmFDf7atpKOPb0oJRliuLsU9ahCuIDRtu5j+xc6R5923UZ7DOWESlbBlHaSsxW Z076SMAwq5JMCf+u2pQqrqAMrgP3Wmvu2envcvumMzH9Ha59N3+FAZUSPE+UISgOguea wjqnlHI+FKFdKoOBui3hE+CME0t4pQqZisLRhuj/POyPqbglOUzoD34HFYnSFiv73ESH Bixet4nE/5jXYdC9zz+21Qj/y0P+iUOzEaiKar4DKnSxhZswF8VaYvCj11d6Acf6u8mH bNYblrrkBEWsqbPbx8hIQEqJsqzIWwRcwPjJ6YDq4ZhzWRv0kIStOEMYNnEV0AoUfmLi QcpQ== X-Gm-Message-State: AOAM53320Xvq9nGStAqfsQEo9rZJVuqMg5LN2fgkYp0Pv73JFZ25FerL 3jw/DtZ75xWSC0LkwY05LgeEreZdmeE= X-Google-Smtp-Source: ABdhPJxOj7CH2EveDsNyuPu/CT3pVIW1pW5vfBboH5UNMiA2rh07R2yKefKvYVB77CzeGzmmQONCfA== X-Received: by 2002:a63:f54c:: with SMTP id e12mr8024311pgk.415.1605707397233; Wed, 18 Nov 2020 05:49:57 -0800 (PST) Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com. [209.85.216.51]) by smtp.gmail.com with ESMTPSA id t10sm7769640pfq.110.2020.11.18.05.49.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 05:49:57 -0800 (PST) Received: by mail-pj1-f51.google.com with SMTP id b12so1141231pjl.0 for ; Wed, 18 Nov 2020 05:49:57 -0800 (PST) X-Received: by 2002:a17:90b:1b52:: with SMTP id nv18mr119138pjb.172.1605707396845; Wed, 18 Nov 2020 05:49:56 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <004b01d6bdab$fbac2af0$f30480d0$@gmail.com> In-Reply-To: <004b01d6bdab$fbac2af0$f30480d0$@gmail.com> From: Ryan Sleevi Date: Wed, 18 Nov 2020 08:49:46 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Santosh Chokhani Cc: LAMPS Content-Type: multipart/alternative; boundary="0000000000000099b405b461e303" Archived-At: Subject: Re: [lamps] The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 13:50:01 -0000 --0000000000000099b405b461e303 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 18, 2020 at 8:09 AM Santosh Chokhani wrote: > Ryan, > > > > It all depends on what the client does. Clearly OCSP RFC authors thought > it useful to indicate this. They could have used your rationale. > This is just an argument to authority that doesn=E2=80=99t actually establi= sh any new information, and itself rests on disproven assumptions about how things would work (=E2=80=9Cthe directory!=E2=80=9D, =E2=80=9Creliable connectivit= y=E2=80=9D, =E2=80=9Chard fail=E2=80=9D). It is the misguided efforts there that inform my criticism, exactly because clients have found necessary to impose local policy on such information, and to otherwise disregard such information, as appropriate. As I mentioned it all depends on if you are in control of the client > consuming these certificates. > I think we agree here, but I can=E2=80=99t help but feel like you=E2=80=99r= e arguing for a hypothetical =E2=80=9Cwhat if clients...=E2=80=9D, and I=E2=80=99m trying t= o highlight that if we=E2=80=99re entertaining hypotheticals, there are far more practical ways= to achieve the implied desired result. However, if we want to continue to entertain such hypotheticals, we need to explicitly state whatever assumptions exist that make this useful, if staying this extension is useful. > > If you are talking about all the X.509 enabled clients out there today, > then you are right, the behavior will be varied as clients are and we do > not clear. > > > > If you want to do something for a client you design for this class of > certificates, I would recommend parking on OCSP-nocheck since its > description in RFC 6960 is closer to what you are saying. > And I=E2=80=99m stating that if you want something for a client you design = for this class of certificates, you can just as easily decide, in your client, to not hard-fail on the absence of the CDP and AIA. Which, incidentally, is the behavior of virtually every implementation out there, since the assumed behavior that made noCheck necessary (hard fail and local client configuration to a local directory) achieved neither =E2=80=9Crough consens= us=E2=80=9D nor =E2=80=9Crunning code=E2=80=9D. So you don=E2=80=99t have to design as if t= hese are inherently true, since in the vast majority of the time, they aren=E2=80=99t, and for = good reason. > > *From:* Ryan Sleevi [mailto:ryan-ietf@sleevi.com] > *Sent:* Wednesday, November 18, 2020 7:34 AM > *To:* Santosh Chokhani > *Cc:* LAMPS > *Subject:* Re: [lamps] The id-ce-noRevAvail extension > > > > Santosh, > > > > This doesn=E2=80=99t really explain the necessity for an extension, and I= =E2=80=99m hoping > that if you believe it necessary, you can describe a concrete processing > model where it does, with reference to RFC 5280. > > > > There are several critical assumptions here that you haven=E2=80=99t actu= ally > elaborated on: > > > > 1. That a client will have a different output based on the presence of > this extension than without. > > > > Can you describe, tangibly, what those outputs are, and how that fits wit= h > today=E2=80=99s RFC 5280 processing model, since you clearly make referen= ce to this > possibility? > > > > 2. That clients, which are updated to support whatever semantics #1 > proposes, have no other way of achieving this result. > > > > The problem here is that in order for an extension to be useful, it needs > to have new semantics (#1), which means the client must update to support > that extension. Since we have to assume the client can update, it doesn= =E2=80=99t > make any sense to suggest this is the only possible solution. > > > > 3. That this is a matter for CA expression, and not local policy. > > > > From what you describe, there=E2=80=99s a clear desire that client behavi= or should > change (#1) based on some direction of the CA (#2). However, honestly and > fully answering #2 requires us to also ask: is this something that the CA > should be defining in the first place, or is this really a matter for loc= al > policy? > > > > To understand this, consider if we assume that there is some > (yet-undefined) processing model associated to the semantics of putting i= t > into an extension, and all clients are updated to these semantics. This > extension is now present in a CA certificate valid for 30 years. Should t= he > client trust that CA or, since it expects revocation details, reject it? = I > should hope the answer is =E2=80=9Creject=E2=80=9D. What about if this wa= s an EE cert, > valid for 1y? Again, I would hope the answer is reject. > > > > What this means is that, even assuming the extension and semantics, > there=E2=80=99s some local policy involved which cannot simply blindly tr= ust the CA > and go =E2=80=9Cwell, they said no revocation would ever be available, an= d that=E2=80=99s > fine by me,=E2=80=9D because to do so would be laughably insecure. So whe= ther or > not a CA is permitted to definitively not provide revocation details then > has to consider local policy about when that is acceptable, which means > that the CA=E2=80=99s explicit expression doesn=E2=80=99t override or rep= lace local policy. > Since local policy is now involved (answering #3), it means we have more > options to solve (#2), including that clients simply update to handle > omitted revocation details to whatever preferred semantics for #1 . > > > > So no, I don=E2=80=99t see the necessity of an explicit extension here. > > > > On Tue, Nov 17, 2020 at 12:58 PM Santosh Chokhani < > santosh.chokhani@gmail.com> wrote: > > DKG, > > This determination should be based on how client behaves when no revocati= on > information can be obtained. > > As to OCSP client policy, clients can go to responder(s) that are locally > configured (causing delays) and come back with no tangible information. > > The question boils down to do you want client to continue and without any > warning or anomaly? If so, that should be indicated in the certificate a= nd > not by omission of CRL DP and OCSP. Again, the client needs to process > that > indication to mean all is well. > > I also do not see a need for both extensions. No-check might not work wi= th > COTS because some existing clients may deal with it for OCSP responder > delegated certificate. > > If this is a client you have control over, I would say you can make eithe= r > extension work. > > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn > Gillmor > Sent: Tuesday, November 17, 2020 12:36 PM > To: Russ Housley ; LAMPS > Subject: Re: [lamps] The id-ce-noRevAvail extension > > On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote: > > Remember that this is part of the LAMPS WG charter: > > > > 1. Specify the use of short-lived X.509 certificates for which no > > revocation information is made available by the Certification Authority= . > > Short-lived certificates have a lifespan that is shorter than the time > > needed to detect, report, and distribute revocation information. As a > > result, revoking short-lived certificates is unnecessary and pointless. > > I agree that this is part of the charter. > > I see two options for signalling that a certificate has no revocation > information available: > > (a) omit any mention of an OCSP responder or CRL location in the > certificate itself. > > or > > (b) explicitly specify the extensions id-ce-noRevAvail and > id-pkix-ocsp-nocheck > > (a) seems like it has the advantage of being simpler. (b) seems to also > create an opportunity for confusion, because a single certificate can now > claim an OCSP responder, a CRL location, *and* specify these locations. > What would that even mean? Is this a new error case for implementations = to > have to check for? > > The only reason to push for (b) is if there is a legitimate case where a > standard policy mechanism needs to be *overridden* for a given certificat= e. > For example, if there is a situation where the CRL location or OCSP > responder for a certificate is published in (and looked for by the relyin= g > party in) the *issuer's* intermdiate CA certificate, but is *not* expecte= d > to also be published in the certificate itself, then we'd need (b) for th= e > CA to be able to override the default location. > > Does such a standard policy exist? I'm not an X.509 expert, so i don't > know > about it. If it does, a pointer to it would clarify the need for (b). > > wrt to OCSP, https://tools.ietf.org/html/rfc6960#section-3 says that the > two > options for finding the OCSP responder location are (1) in the certificat= e > itself whose status is being checked, or (2) "configured locally at the > OCSP > client". > > If the only scenario anyone can produce is "configured locally at the OCS= P > client," then presumably such a policy requires identifying *which* > certificates to apply such an OCSP check to. > > It seems like the solution for that use case is that local configuration = to > match on a different set of certificates. Introducing redundancy (and ro= om > for error) in all certificates seems like a bad tradeoff for local policy > that could be updated independently. > > --dkg > > _______________________________________________ > 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 > --0000000000000099b405b461e303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 18, 2020 at 8:09 AM Santosh Chokhani <santosh.chokhani@gmail.com> = wrote:
Ryan,

=C2=A0

It all depends on what the client does.=C2=A0 Clear= ly OCSP RFC authors thought it useful to indicate this.=C2=A0 They could ha= ve used your rationale.

This is just an argument to authority that doesn=E2=80=99t actually estab= lish any new information, and itself rests on disproven assumptions about h= ow things would work (=E2=80=9Cthe directory!=E2=80=9D, =E2=80=9Creliable c= onnectivity=E2=80=9D, =E2=80=9Chard fail=E2=80=9D).
=
It is the misguided efforts there that inform m= y criticism, exactly because clients have found necessary to impose local p= olicy on such information, and to otherwise disregard such information, as = appropriate.

As I ment= ioned it all depends on if you are in control of the client consuming these= certificates.

I think= we agree here, but I can=E2=80=99t help but feel like you=E2=80=99re argui= ng for a hypothetical =E2=80=9Cwhat if clients...=E2=80=9D, and I=E2=80=99m= trying to highlight that if we=E2=80=99re entertaining hypotheticals, ther= e are far more practical ways to achieve the implied desired result.
<= div dir=3D"auto">
However, if we want to continu= e to entertain such hypotheticals, we need to explicitly state whatever ass= umptions exist that make this useful, if staying this extension is useful.<= /div>


=C2=A0

If you are talking about all the X.509 enabled clients out there today, th= en you are right, the behavior will be varied as clients are and we do not = clear.

=C2=A0

If you want = to do something for a client you design for this class of certificates, I w= ould recommend parking on OCSP-nocheck since its description in RFC 6960 is= closer to what you are saying.

And I=E2=80=99m stating that if you want something for a client y= ou design for this class of certificates, you can just as easily decide, in= your client, to not hard-fail on the absence of the CDP and AIA. Which, in= cidentally, is the behavior of virtually every implementation out there, si= nce the assumed behavior that made noCheck necessary (hard fail and local c= lient configuration to a local directory) achieved neither =E2=80=9Crough c= onsensus=E2=80=9D nor =E2=80=9Crunning code=E2=80=9D. So you don=E2=80=99t = have to design as if these are inherently true, since in the vast majority = of the time, they aren=E2=80=99t, and for good reason.


<= u>

=C2=A0

From: Ryan Sleevi [mailto:ryan-ietf@sleevi.com]
Sent: Wed= nesday, November 18, 2020 7:34 AM
To: Santosh Chokhani <santosh.chokhani@= gmail.com>
Cc: LAMPS <spasm@ietf.org>
Subject: Re: [lamps] Th= e id-ce-noRevAvail extension

=C2=A0

Santosh,=

=C2=A0

This doesn=E2=80=99t really explain the necessity for = an extension, and I=E2=80=99m hoping that if you believe it necessary, you = can describe a concrete processing model where it does, with reference to R= FC 5280.

=C2=A0

There are several critical assum= ptions here that you haven=E2=80=99t actually elaborated on:<= /p>

=C2=A0

1. That a client will have a different output based on = the presence of this extension than without.

=C2=A0

Can you describe, tangibly, what those outputs are, and how that fits w= ith today=E2=80=99s RFC 5280 processing model, since you clearly make refer= ence to this possibility?

=C2=A0

2. That clients= , which are updated to support whatever semantics #1 proposes, have no othe= r way of achieving this result.

=C2=A0

The probl= em here is that in order for an extension to be useful, it needs to have ne= w semantics (#1), which means the client must update to support that extens= ion. Since we have to assume the client can update, it doesn=E2=80=99t make= any sense to suggest this is the only possible solution.

=

=C2=A0

3. That this is a matter for CA expression, and not local = policy.

=C2=A0=

From what you describe, there=E2= =80=99s a clear desire that client behavior should change (#1) based on som= e direction of the CA (#2). However, honestly and fully answering #2 requir= es us to also ask: is this something that the CA should be defining in the = first place, or is this really a matter for local policy?

=

=C2=A0

To understand this, consider if we assume that there is so= me (yet-undefined) processing model associated to the semantics of putting = it into an extension, and all clients are updated to these semantics. This = extension is now present in a CA certificate valid for 30 years. Should the= client trust that CA or, since it expects revocation details, reject it? I= should hope the answer is =E2=80=9Creject=E2=80=9D. What about if this was= an EE cert, valid for 1y? Again, I would hope the answer is reject.=

=C2=A0

=

What this means is that, even assuming the exte= nsion and semantics, there=E2=80=99s some local policy involved which canno= t simply blindly trust the CA and go =E2=80=9Cwell, they said no revocation= would ever be available, and that=E2=80=99s fine by me,=E2=80=9D because t= o do so would be laughably insecure. So whether or not a CA is permitted to= definitively not provide revocation details then has to consider local pol= icy about when that is acceptable, which means that the CA=E2=80=99s explic= it expression doesn=E2=80=99t override or replace local policy. Since local= policy is now involved (answering #3), it means we have more options to so= lve (#2), including that clients simply update to handle omitted revocation= details to whatever preferred semantics for #1 .

=C2=A0

So no, I don=E2=80=99t see the necessity of an explicit extension = here.

=C2=A0

On Tue, Nov 17, 2020 at 12:58 PM Sa= ntosh Chokhani <santosh.chokhani@gmail.com> wrote:

DKG,

This determination should be based on how client behave= s when no revocation
information can be obtained.=C2=A0

As to OC= SP client policy, clients can go to responder(s) that are locally
config= ured (causing delays) and come back with no tangible information.

Th= e question boils down to do you want client to continue and without any
= warning or anomaly?=C2=A0 If so, that should be indicated in the certificat= e and
not by omission of CRL DP and OCSP.=C2=A0 Again, the client needs = to process that
indication to mean all is well.

I also do not see= a need for both extensions.=C2=A0 No-check might not work with
COTS bec= ause some existing clients may deal with it for OCSP responder
delegated= certificate.=C2=A0

If this is a client you have control over, I wo= uld say you can make either
extension work.

-----Original Message= -----
From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor<= br>Sent: Tuesday, November 17, 2020 12:36 PM
To: Russ Housley <housley@vigilsec.com>; LAMPS <spasm@= ietf.org>
Subject: Re: [lamps] The id-ce-noRevAvail extension
=
On Tue 2020-11-17 03:25:08 -0500, Russ Housley wrote:
> Remember = that this is part of the LAMPS WG charter:
>
> 1. Specify the u= se of short-lived X.509 certificates for which no
> revocation infor= mation is made available by the Certification Authority.
> Short-live= d certificates have a lifespan that is shorter than the time
> neede= d to detect, report, and distribute revocation information. As a
> r= esult, revoking short-lived certificates is unnecessary and pointless.
<= br>I agree that this is part of the charter.

I see two options for s= ignalling that a certificate has no revocation
information available:
=C2=A0(a) omit any mention of an OCSP responder or CRL location in the=
=C2=A0 =C2=A0 =C2=A0certificate itself.

or

=C2=A0(b) expl= icitly specify the extensions id-ce-noRevAvail and
=C2=A0 =C2=A0 =C2=A0i= d-pkix-ocsp-nocheck

(a) seems like it has the advantage of being sim= pler.=C2=A0 (b) seems to also
create an opportunity for confusion, becau= se a single certificate can now
claim an OCSP responder, a CRL location,= *and* specify these locations.
What would that even mean?=C2=A0 Is this= a new error case for implementations to
have to check for?

The o= nly reason to push for (b) is if there is a legitimate case where a
stan= dard policy mechanism needs to be *overridden* for a given certificate.
= For example, if there is a situation where the CRL location or OCSP
resp= onder for a certificate is published in (and looked for by the relying
p= arty in) the *issuer's* intermdiate CA certificate, but is *not* expect= ed
to also be published in the certificate itself, then we'd need (b= ) for the
CA to be able to override the default location.

Does su= ch a standard policy exist?=C2=A0 I'm not an X.509 expert, so i don'= ;t know
about it.=C2=A0 If it does, a pointer to it would clarify the ne= ed for (b).

wrt to OCSP, https://tools.ietf.org/html/rfc6960#sectio= n-3 says that the two
options for finding the OCSP responder locatio= n are (1) in the certificate
itself whose status is being checked, or (2= ) "configured locally at the OCSP
client".

If the only = scenario anyone can produce is "configured locally at the OCSP
clie= nt," then presumably such a policy requires identifying *which*
cer= tificates to apply such an OCSP check to.

It seems like the solution= for that use case is that local configuration to
match on a different s= et of certificates.=C2=A0 Introducing redundancy (and room
for error) in= all certificates seems like a bad tradeoff for local policy
that could = be updated independently.

=C2=A0 =C2=A0 =C2=A0 --dkg

________= _______________________________________
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
--0000000000000099b405b461e303-- From nobody Wed Nov 18 11:04:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75253A09D3 for ; Wed, 18 Nov 2020 11:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fsJfoJu1g5jD for ; Wed, 18 Nov 2020 11:04:35 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932DE3A09D1 for ; Wed, 18 Nov 2020 11:04:35 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJ4XMe017488; Wed, 18 Nov 2020 19:04:33 GMT 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=oMj539R1a/jeHhpWS78Txl4+ZWNM7tq2pl7onzOjBLQ=; b=GuHvnp4D/Ib91LuytYe6MYjvKCSlUqp5ROGiioX6i24FcnGdYck2N6+Gf0MF+lpY40wj 5Q0UWGVIf7CbmF8yf2h5ajdBVaiJHvVpOYpVlAEMOJ4HHo9P8VOl6GsdB3L0B2Fdh13j RPMuTwz3rWEftWsJpJY1F2XvSo8YNrCSm3wYC9R/llMV7uZiI+rkzmXI7WeFCinHNimO N55huXMsp9GVo/bugy92xa+dNBHr8kQvEAM808M+aab8Lq+e1c+o6vk2bczznf2Vwrvo TowqACektRUHa2RQ6lTX+cWJHjGjRh0IudjnDppIYkrZMOyW4I9EgqRUVjYgP1jHOCzn 4w== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 34w7pwmfaf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 19:04:33 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJ3rGV001512; Wed, 18 Nov 2020 14:04:32 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint7.akamai.com with ESMTP id 34tbf35pjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 14:04:32 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 13:04:31 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 13:04:31 -0600 From: "Salz, Rich" To: Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOA Date: Wed, 18 Nov 2020 19:04:30 +0000 Message-ID: <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_33267B3B419845D1A7BCBE9E282292ECakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=860 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180132 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 clxscore=1011 adultscore=0 bulkscore=0 priorityscore=1501 phishscore=0 spamscore=0 suspectscore=0 impostorscore=0 mlxlogscore=777 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180132 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:04:37 -0000 --_000_33267B3B419845D1A7BCBE9E282292ECakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB0aGluayB5b3UgbWlnaHQgYmUgbWlzc2luZyBzb21ldGhpbmcsIGJlY2F1c2UgYXMg SSBleHBsYWluZWQsIGFuZCBhcyBES0cgbWVudGlvbmVkLCB0aGUgb21pc3Npb24gb2Ygc3VjaCBp bmZvcm1hdGlvbiB3aXRoaW4gYSBjZXJ0aWZpY2F0ZSBpcyBzdWZmaWNpZW50Lg0KDQpJIGRpc2Fn cmVlIGZvciByZWFzb25zIGFzIEkgZGVzY3JpYmVkLiAgSW4gYWRkaXRpb24sIGFuIFJQIG1pZ2h0 IGhhdmUgYSBnbG9iYWwgbGlzdCBvZiBPQ1NQIHJlc3BvbmRlciBjb25maWd1cmVkLg0KDQoNCiAg KiAgIElmIHlvdSBiZWxpZXZlIHRoZXJlIGlzIGEgbmVjZXNzaXR5IGZvciBhbiBleHRlbnNpb24s IHlvdSBuZWVkIHRvIGRlc2NyaWJlIGEgcHJvY2Vzc2luZyBtb2RlbCBvZiBSRkMgNTI4MCB0aGF0 IGJlaGF2ZXMgZGlmZmVyZW50bHkuIFRoaXMgc2hvdWxkIGJlIGEgaG9wZWZ1bGx5IGVhc3kgZXhl cmNpc2UuDQoNCklmIHRoZSBleHRlbnNpb24gaXMgc3BlY2lmaWVkLCB0aGVuIHRoZSBDQSBpbmRp Y2F0ZXMgdGhhdCByZXZvY2F0aW9uIGluZm9ybWF0aW9uLCBzdWNoIGFzIE9DU1Agb3IgQ1JMcywg d2lsbCBub3QgYmUgcHJvdmlkZWQuIFJlbHlpbmcgcGFydGllcyBhcmUgZnJlZSB0byB1c2UgYW5k IHByb2Nlc3MgYW55IHN1Y2ggaW5mb3JtYXRpb24gdGhleSBoYXZlIGF2YWlsYWJsZSB0byB0aGVt LiBJRiB0aGUgZXh0ZW5zaW9uIGlzIG1hcmtlZCBDUklUSUNBTCB0aGFuIHJlbHlpbmcgcGFydGll cyBNVVNUIE5PVCB1c2Ugc3VjaCBpbmZvcm1hdGlvbi4NCg0K --_000_33267B3B419845D1A7BCBE9E282292ECakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIwODY5NTU1MzM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE3NTU2NDAwNDQgOTQ0NDMzMjU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1mb250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkkgdGhpbmsg eW91IG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nLCBiZWNhdXNlIGFzIEkgZXhwbGFpbmVkLCBh bmQgYXMgREtHIG1lbnRpb25lZCwgdGhlIG9taXNzaW9uIG9mIHN1Y2ggaW5mb3JtYXRpb24gd2l0 aGluIGEgY2VydGlmaWNhdGUgaXMgc3VmZmljaWVudC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkaXNhZ3JlZSBmb3IgcmVhc29ucyBhcyBJIGRlc2NyaWJl ZC4mbmJzcDsgSW4gYWRkaXRpb24sIGFuIFJQIG1pZ2h0IGhhdmUgYSBnbG9iYWwgbGlzdCBvZiBP Q1NQIHJlc3BvbmRlciBjb25maWd1cmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SWYgeW91IGJl bGlldmUgdGhlcmUgaXMgYSBuZWNlc3NpdHkgZm9yIGFuIGV4dGVuc2lvbiwgeW91IG5lZWQgdG8g ZGVzY3JpYmUgYSBwcm9jZXNzaW5nIG1vZGVsIG9mIFJGQyA1MjgwIHRoYXQgYmVoYXZlcyBkaWZm ZXJlbnRseS4gVGhpcyBzaG91bGQgYmUgYSBob3BlZnVsbHkgZWFzeSBleGVyY2lzZS48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGV4dGVuc2lvbiBp cyBzcGVjaWZpZWQsIHRoZW4gdGhlIENBIGluZGljYXRlcyB0aGF0IHJldm9jYXRpb24gaW5mb3Jt YXRpb24sIHN1Y2ggYXMgT0NTUCBvciBDUkxzLCB3aWxsIG5vdCBiZSBwcm92aWRlZC4gUmVseWlu ZyBwYXJ0aWVzIGFyZSBmcmVlIHRvIHVzZSBhbmQgcHJvY2VzcyBhbnkgc3VjaCBpbmZvcm1hdGlv biB0aGV5IGhhdmUgYXZhaWxhYmxlIHRvIHRoZW0uIElGIHRoZSBleHRlbnNpb24NCiBpcyBtYXJr ZWQgQ1JJVElDQUwgdGhhbiByZWx5aW5nIHBhcnRpZXMgTVVTVCBOT1QgdXNlIHN1Y2ggaW5mb3Jt YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_33267B3B419845D1A7BCBE9E282292ECakamaicom_-- From nobody Wed Nov 18 11:08:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD20A3A09D5 for ; Wed, 18 Nov 2020 11:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 7aeQbb0ZNCAG for ; Wed, 18 Nov 2020 11:08:36 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 DA4F73A09D4 for ; Wed, 18 Nov 2020 11:08:35 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id f93so2438058qtb.10 for ; Wed, 18 Nov 2020 11:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=2KjHr+iD0Bfhf9kkTcay74A9t4FYPrt/K3BYKMC+JPg=; b=nW3QysZIzulnH5Cg1pxx4uEX5oM0lbZXhZB31AemLr1teTleGBHIuvtHFltRxO9q39 agJ3hf2DHD3B7T/8TdxKBSK3Vcwftt76vrz5V6u4mHAxtX/JodimmqxiOlkwrTv3jPOG xNN+ufO5Pioc11rZHmXt2G+pBZ2fMj+MO+DZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=2KjHr+iD0Bfhf9kkTcay74A9t4FYPrt/K3BYKMC+JPg=; b=W/LqoI+ULFm6lENC4QxQ8UACkL5e1r88Mo0tjPnmvXKYFkHtGRgQNR92yE6uWiw61W kCTwPXcsFiOWvPEunvb/rSE1Hc4YnugzXHDV5sf79cNtwdJfYAl3qrFOChBs8g3/b0zb qejntbxpTsDWkz+HXKcGhnHFt85LQQQXFKzWNX/BmB+Sgu2Jy19+NmI+3baJ9g3NkR3f 0LMSUJQOyWcl6/NDNAlwNB/bI13Sx8CwQODBYBOTF4IWZyJ17V7hEPRQxXs+/BUge9Sp So54bbAzKfRhZaJo3Cprc9kax6vIMKY51Tm7/aV+JyWTm3ZhsHtID7uodr1ynRU5Frjj tv0A== X-Gm-Message-State: AOAM533FvGtPFdAJk0n5FhCUX5GtBTwhuYmyQR86xfgUcOgVY8uCZgLj /oW566LrWYI6TI6didsY0jq6/A== X-Google-Smtp-Source: ABdhPJx172Uk0sfh89lG1p3bvyi4JaeezfoDjK+t99X8FD2+fyJFDnB086lUwJzq4GxhmMLotAl4fg== X-Received: by 2002:aed:26a3:: with SMTP id q32mr6174738qtd.68.1605726514638; Wed, 18 Nov 2020 11:08:34 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id i4sm5105304qti.78.2020.11.18.11.08.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 11:08:33 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 14:08:33 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> In-Reply-To: <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688553313_1934350384" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:08:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688553313_1934350384 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable If the extension is specified, then the CA indicates that revocation inform= ation, such as OCSP or CRLs, will not be provided. Relying parties are free = to use and process any such information they have available to them. IF the = extension is marked CRITICAL than relying parties MUST NOT use such informat= ion. =20 [CW] It is none of the CA=E2=80=99s business if I elect to consider a certificate= revoked. --B_3688553313_1934350384 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

If the extension is specified, then the CA= indicates that revocation information, such as OCSP or CRLs, will not be pr= ovided. Relying parties are free to use and process any such information the= y have available to them. IF the extension is marked CRITICAL than relying p= arties MUST NOT use such information.

=  

[CW] It is none of the CA=E2=80=99s business if= I elect to consider a certificate revoked.

--B_3688553313_1934350384-- From nobody Wed Nov 18 11:33:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0BC3A0ACB for ; Wed, 18 Nov 2020 11:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qm2Yfw79L7VV for ; Wed, 18 Nov 2020 11:33:29 -0800 (PST) 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 ADAD63A0AC7 for ; Wed, 18 Nov 2020 11:33:29 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJMPBJ016100; Wed, 18 Nov 2020 19:33:27 GMT 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=Y4FZF7S+D24CuyvrGFwqk/hcLa8dMjQGjxVIlxbL4DA=; b=ivUvy1ntHLfW+uL0DGG7rgtI/iOmitpZyRSDJCWXvdthZKGaoqvcERdj8/8hB3zZvJYM 2foOAMyKL51bz9ffUM3FJrO5CVnVW1ZGTM2VTF1y+Mbeq9shIRdsuDSuTYZDjR1R7t5V yJE8Pesf6htSOj2i4N+hpCeaGB8+BsgoBbkY5QvRe6pOZXjAooE28FZvRuUYORv+LAMl NnoCHHTKYGUa8Es5dn0t83H8MHsOK39tc02SFKoCpYs0NS5F9k4qWjiCRfQ64azD6ts8 dLHqkfLVJG777NlRGwlKOuZ6+XYZW7quBKX4Hoi4creSOufttNgRUNK4X9x0XhCH4W8T lw== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34w7r9dqdh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 19:33:27 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJKWC7031192; Wed, 18 Nov 2020 14:33:26 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 34tbf2ns2p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 14:33:26 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 13:33:25 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 13:33:24 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAA== Date: Wed, 18 Nov 2020 19:33:23 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_CE73C7A89F774B849BF57484E6461879akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxlogscore=774 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 impostorscore=0 mlxscore=0 mlxlogscore=690 lowpriorityscore=0 clxscore=1011 bulkscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180134 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:33:31 -0000 --_000_CE73C7A89F774B849BF57484E6461879akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgW0NXXSBJdCBpcyBub25lIG9mIHRoZSBDQeKAmXMgYnVzaW5lc3MgaWYgSSBlbGVjdCB0 byBjb25zaWRlciBhIGNlcnRpZmljYXRlIHJldm9rZWQuDQoNClN1cmUsIHlvdSBjYW4gZG8gd2hh dGV2ZXIgb3V0IG9mIGJhbmQgcHJvY2Vzc2luZyB5b3Ugd2FudC4NCg== --_000_CE73C7A89F774B849BF57484E6461879akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <00D0C229FDAE0F45B6E93D4DC564DF90@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEwMzQzMDMzODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0zMTc0MTQ4NDYgMTc1MjA4MDI0NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5bQ1ddIEl0IGlz IG5vbmUgb2YgdGhlIENB4oCZcyBidXNpbmVzcyBpZiBJIGVsZWN0IHRvIGNvbnNpZGVyIGEgY2Vy dGlmaWNhdGUgcmV2b2tlZC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgeW91 IGNhbiBkbyB3aGF0ZXZlciBvdXQgb2YgYmFuZCBwcm9jZXNzaW5nIHlvdSB3YW50LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE73C7A89F774B849BF57484E6461879akamaicom_-- From nobody Wed Nov 18 11:42:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE83A0AF7 for ; Wed, 18 Nov 2020 11:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 72XbZ--VZ9TZ for ; Wed, 18 Nov 2020 11:42:55 -0800 (PST) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 CF3033A0AF5 for ; Wed, 18 Nov 2020 11:42:54 -0800 (PST) Received: by mail-qv1-xf30.google.com with SMTP id u23so1657611qvf.1 for ; Wed, 18 Nov 2020 11:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=qbXn4NxAad9eyRHSbVDYhD9d9YUXiWHYCqSrq5dYXyI=; b=ZeScpRuUw7xQZ3XijdtZmAxTsq/hfitDX7a3WkYDmQBQmOeZTqiJY0cPrgtp9TrYzb Ri9gBtNKNA+nmUk5Ly982kfhj2Na6qKdW0dAANaME/sx8b9UurfWG4uAm88rN2lO5NeM r3AKBC7aQ5Lzf0Cbl4rlJimmfsrk4eXpmyC9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=qbXn4NxAad9eyRHSbVDYhD9d9YUXiWHYCqSrq5dYXyI=; b=rEO1z/RJzWE+//u80TVoYR7eodqzQBZZlJ2ZzhFMYv4FZkq2mqSw7L0PG9rp698O5a m7Kg62dmBlWjoRs3PDXn6Fp57619P6OsK4vEK+1EmKZKU8jUrUwKAFdzN5g86wQzhHpq u8vDR8Y8SwwFL1wi1dIqmIsk3i+kZlNEXmzpvl9FrKelklQHmIoyA3SRsc/rh4a7o610 2Zwmy4329NF2RoC7xw32Tb5H/IQrX+Pa8F4XhgaDLMhIL4ERlD8xPtO9E2FRu40J8CND FA3IaTQ/RM6IVvzV+vooRsjdC3pmk4UIisfLZAI1YMXn0FqSiHgRSejq1GsFXHQjFM9I Qpnw== X-Gm-Message-State: AOAM532WU0Cccbamj/UFWKYEbHDLvOfweTXGLfDCKHYPsPS5EqXEFxQZ Z/5rGfOygp673u+qwWvSwhXokg== X-Google-Smtp-Source: ABdhPJzK44a7/On+gDpGaQGXkDhze5BPDr2NdyPZ+TsW4GVnBqYGspPHhsvJrvifN2kkbc/LYEO4aA== X-Received: by 2002:a05:6214:2b4:: with SMTP id m20mr2635067qvv.34.1605728573532; Wed, 18 Nov 2020 11:42:53 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id k11sm17200157qtu.45.2020.11.18.11.42.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 11:42:52 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 14:42:52 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688555372_53014021" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:42:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688555372_53014021 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Then I mistook your =E2=80=9CIF the extension is marked CRITICAL than relying par= ties MUST NOT use such information=E2=80=9D as standards language to the contrary. =20 From: "Salz, Rich" Date: Wednesday, November 18, 2020 at 2:33 PM To: Carl Wallace , Ryan Sleevi , Mike Ounsworth Cc: LAMPS , Santosh Chokhani Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension =20 [CW] It is none of the CA=E2=80=99s business if I elect to consider a certificate= revoked. =20 Sure, you can do whatever out of band processing you want. --B_3688555372_53014021 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable --B_3688555372_53014021-- From nobody Wed Nov 18 11:44:31 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387043A0B02 for ; Wed, 18 Nov 2020 11:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 RLZs_OE7Lqcs for ; Wed, 18 Nov 2020 11:44:28 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9B13A0AF5 for ; Wed, 18 Nov 2020 11:44:28 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJYgjx000544; Wed, 18 Nov 2020 19:44:22 GMT 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=Uz/d+nI1+kFeOmfkJKy7CZjwzffCGO+HxowrK+WJ7zk=; b=RQZSZSgBElQK86QdAToUUXJAFBRxjxwW8azOq7XIDdZBnruVnDfNTngcpCIhDbTMcoJf xd8eawYNfKsLVeavKvyd9Lj1F2gPKezbNFs21RuyaeKi9TSg5XAJ26+OTnB4IYNkRkhV pMCQqsTcKubKzsz6SCV3mHpR5uKidunEeHNaCsU/EiUsfdIln7A64X/yLcRtFpDMbNpR 7zcEhAX8X0Q3r+nOHoTjLUCjz+4smudjuWGPY+jRDoKvd26rbhgnhB3BHUtr1MOiw+lB 6IExY18mjNaArKJJ27KEaIAN5loidRmrmyPAdrQUUvRY7Yts/aTuq/gx3W7OFy2Dq/aN gA== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 34w7pwnxdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 19:44:21 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJZMRL008615; Wed, 18 Nov 2020 14:44:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint8.akamai.com with ESMTP id 34tbf2dt6p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 14:44:21 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 13:44:20 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 13:44:20 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloA= Date: Wed, 18 Nov 2020 19:44:19 +0000 Message-ID: <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> In-Reply-To: <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_2CB0AE8ADF4E403AA93934C6DF9106C9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 mlxlogscore=782 phishscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_06:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 bulkscore=0 priorityscore=1501 phishscore=0 spamscore=0 suspectscore=0 impostorscore=0 mlxlogscore=703 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180135 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:44:30 -0000 --_000_2CB0AE8ADF4E403AA93934C6DF9106C9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIFRoZW4gSSBtaXN0b29rIHlvdXIg4oCcSUYgdGhlIGV4dGVuc2lvbiBpcyBtYXJr ZWQgQ1JJVElDQUwgdGhhbiByZWx5aW5nIHBhcnRpZXMgTVVTVCBOT1QgdXNlIHN1Y2ggaW5mb3Jt YXRpb27igJ0gYXMgc3RhbmRhcmRzIGxhbmd1YWdlIHRvIHRoZSBjb250cmFyeS4NCg0KQW55dGhp bmcgb3V0IG9mIGJhbmQsIGxpa2UgeW91ciBwZXJzb25hbCBtYWdpYyA4IGJhbGwsIGlzIG91dCBv ZiBzY29wZSBmb3IgNTI4MCBwcm9jZXNzaW5nIHJ1bGVzLg0K --_000_2CB0AE8ADF4E403AA93934C6DF9106C9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8949399E8F794642A296DC43256B81D3@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEwMzQzMDMzODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0zMTc0MTQ4NDYgMTc1MjA4MDI0NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjAx ODIyODg2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MDI4MDMzMjQ7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMg0KCXttc28tbGlzdC1pZDoxMzI1NjIzNzg4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkzMTQ3MzQ4MiAtMzMxMjA4OTU0IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlz dCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPlRo ZW4gSSBtaXN0b29rIHlvdXIg4oCcPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JRiB0aGUgZXh0 ZW5zaW9uIGlzIG1hcmtlZCBDUklUSUNBTCB0aGFuIHJlbHlpbmcgcGFydGllcyBNVVNUIE5PVCB1 c2Ugc3VjaCBpbmZvcm1hdGlvbuKAnSBhcyBzdGFuZGFyZHMgbGFuZ3VhZ2UgdG8gdGhlIGNvbnRy YXJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55dGhpbmcgb3V0IG9m IGJhbmQsIGxpa2UgeW91ciBwZXJzb25hbCBtYWdpYyA4IGJhbGwsIGlzIG91dCBvZiBzY29wZSBm b3IgNTI4MCBwcm9jZXNzaW5nIHJ1bGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_2CB0AE8ADF4E403AA93934C6DF9106C9akamaicom_-- From nobody Wed Nov 18 11:58:55 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D443C3A0B45 for ; Wed, 18 Nov 2020 11:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 vfGlhltM5I1Y for ; Wed, 18 Nov 2020 11:58:51 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 58E4A3A0B3B for ; Wed, 18 Nov 2020 11:58:51 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id r7so3102160qkf.3 for ; Wed, 18 Nov 2020 11:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=ZIUkURLCr90GcyEwvO1racQK1r2H0SMBloV32CVOTnc=; b=xXmZGnaUM8gqka31kgzCuOUXWPda+fcfWaDz0yvFfAY4Gk7zRKbZmSswHXDjrLc2Cd hDN1I2UR+WkkKSTODUdxQUBQb4IyrWqRuDRY+n+m6+WXHRd2qxGMJO6V/uCFTOpTMKiV ubUteOYboEUEPnIx7rFSkzYmerbV/X/1k+1nk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=ZIUkURLCr90GcyEwvO1racQK1r2H0SMBloV32CVOTnc=; b=LmHuH0QYSl9o2TxqpW5wP0Qc6MFFYGeqJvT0xcx0S7sWHyIxcmQpfScAm+Z6r/Ba3W Uytgk8YQOOhZwnOcfpZC50ep0yLQYVnPNnjdMD+Zn84YhpbcZ1WLSJzVtDeabzASMz8s bY51z4g9A7N+3TjlxKUsXMY/YShfhNcxhGavZSLsR2FQIgzkIYBWzqE0KdHH1J54rGmY aPE/Yz4ahJse5fOK9juOxEz9Hr0QqgG5/R6eL/jXhIeUw6ngi+wJIyxXwHF6ikR65kZS Kd/2CATx9ftwn31N6OPqp/TYpnO2NweC/i9urSZOYXzLLbDCahhRnoEYIkOQgUByc8ze 45Ww== X-Gm-Message-State: AOAM530AoqHTrtKTvk/VyzEhRM18Zl9ytYoVyIBvtXpsAHQKKD6xO+Ul PVfFPkLjytydpxwQtUENl3ofSA== X-Google-Smtp-Source: ABdhPJzlnFDJJxUaGWbQH5eqJvbTH/+I00Bxniadq+plRXs9rombfBXnGCOX3/BPgI5IsewxPCPDiA== X-Received: by 2002:a37:bdc5:: with SMTP id n188mr6596321qkf.95.1605729530247; Wed, 18 Nov 2020 11:58:50 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id q15sm16991016qki.13.2020.11.18.11.58.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 11:58:49 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 14:58:49 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> In-Reply-To: <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688556329_1364352280" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 19:58:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688556329_1364352280 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Anything out of band, like your personal magic 8 ball, is out of scope for = 5280 processing rules. =20 [CW] The MUST NOT in your proposed definition certainly appears to try to t= ell me what to do with my personal magic 8 ball: =E2=80=9CRelying parties are free= to use and process any such information they have available to them. IF the= extension is marked CRITICAL than relying parties MUST NOT use such informa= tion.=E2=80=9D I agree this is out of scope of 5280 processing rules and suggest t= hat it is out of scope for standardizing at all (so we don=E2=80=99t need the prop= osed definition). +1 for Ryan Sleevi=E2=80=99s notes throughout this thread. --B_3688556329_1364352280 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Anything out of band, like your personal m= agic 8 ball, is out of scope for 5280 processing rules.

 

[CW] The MUST NOT in yo= ur proposed definition certainly appears to try to tell me what to do with m= y personal magic 8 ball: =E2=80=9CRelying parties are fr= ee to use and process any such information they have available to them. IF t= he extension is marked CRITICAL than relying parties MUST NOT use such infor= mation.=E2=80=9D I agree this is out of scope of 5280 processing rules and = suggest that it is out of scope for standardizing at all (so we don=E2=80=99t need= the proposed definition). +1 for Ryan Sleevi=E2=80=99s notes throughout this thre= ad.

--B_3688556329_1364352280-- From nobody Wed Nov 18 12:01:55 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216853A0B6E for ; Wed, 18 Nov 2020 12:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nlTS6eLO93b8 for ; Wed, 18 Nov 2020 12:01:52 -0800 (PST) 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 BF37F3A0F74 for ; Wed, 18 Nov 2020 12:01:19 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AIK0AoZ022298; Wed, 18 Nov 2020 20:01:06 GMT 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=CrmVXRi38QiksMOVjQmM1Mz1bCqUtAgSlAYev1haCwE=; b=mrpsYQMHPNseNwwwTwLpH85Gem0NPHenQZ2u75u9H3YaVVN//ArqQCBn78OT8XYLV4iI okZvmk86tKBovYUjKDVpckLBGgdBNsOb59zxysAUeYFvxTLIpUSqiQFtPLS63Pr9XaWH lG592Qbic43SP72Brq54vg5e2BmJcwNizDFibEOTQ4cT6Frza4UkuJkhSty67S6/+20c D1Wur3mZWMAHGULiW4vRwMn7bzXQFMmkLL45wNLdrU9NIMYc0Cez1DqoCo/aWAlF9a6C iDsv0dH7vR2SpgMRE1xKh8FLL7W5em7+gPRS+UKvW6MsA0d9BVuHn6rWN1lhq8Y6g86T 8A== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 34w7s86p0a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 20:01:06 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIJo4HK014839; Wed, 18 Nov 2020 15:01:05 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint7.akamai.com with ESMTP id 34tbf360fn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 15:01:05 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 14:01:04 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 14:01:04 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0A Date: Wed, 18 Nov 2020 20:01:03 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> In-Reply-To: <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_D7B4E753E934460690EEEC0C0A7FDC40akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=996 suspectscore=0 impostorscore=0 adultscore=0 clxscore=1015 phishscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180139 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 20:01:54 -0000 --_000_D7B4E753E934460690EEEC0C0A7FDC40akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIGFncmVlIHRoaXMgaXMgb3V0IG9mIHNjb3BlIG9mIDUyODAgcHJvY2Vzc2luZyBydWxlcw0K DQpIb3cgZG8geW91IGZlZWwgYm91dCBPQ1NQLW11c3QtY2hlY2s/ICBIb3cgZG8geW91IGZlZWwg YWJvdXQgZm9sbG93aW5nIGFsbCBBSUEgdmFsdWVzPw0KDQo+IHN1Z2dlc3QgdGhhdCBpdCBpcyBv dXQgb2Ygc2NvcGUgZm9yIHN0YW5kYXJkaXppbmcgYXQgYWxsIChzbyB3ZSBkb27igJl0IG5lZWQg dGhlIHByb3Bvc2VkIGRlZmluaXRpb24pLg0KDQpXZSBuZWVkIGl0IHN0YW5kYXJkaXplZCBzbyB0 aGF0IG11bHRpcGxlIHBhcnRpZXMg4oCTIGFsbCB0aGUgUlDigJlzLCBhbGwgdGhlIENB4oCZcyBh bmQgYWxsIHRoZSBjdXN0b21lcnMg4oCTIGhhdmUgY29tbW9uIGV4cGVjdGF0aW9ucy4NCg== --_000_D7B4E753E934460690EEEC0C0A7FDC40akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A44EFA3C7C1574E8AD27C1D832DDA83@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwvYj4gSSBhZ3JlZSB0aGlzIGlzIG91dCBvZiBz Y29wZSBvZiA1MjgwIHByb2Nlc3NpbmcgcnVsZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93 IGRvIHlvdSBmZWVsIGJvdXQgT0NTUC1tdXN0LWNoZWNrPyZuYnNwOyBIb3cgZG8geW91IGZlZWwg YWJvdXQgZm9sbG93aW5nIGFsbCBBSUEgdmFsdWVzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7IHN1Z2dlc3QgdGhhdCBpdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHN0YW5kYXJkaXppbmcgYXQg YWxsIChzbyB3ZSBkb27igJl0IG5lZWQgdGhlIHByb3Bvc2VkIGRlZmluaXRpb24pLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZSBuZWVkIGl0IHN0YW5kYXJkaXplZCBzbyB0aGF0IG11bHRpcGxl IHBhcnRpZXMg4oCTIGFsbCB0aGUgUlDigJlzLCBhbGwgdGhlIENB4oCZcyBhbmQgYWxsIHRoZSBj dXN0b21lcnMg4oCTIGhhdmUgY29tbW9uIGV4cGVjdGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D7B4E753E934460690EEEC0C0A7FDC40akamaicom_-- From nobody Wed Nov 18 12:05:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156153A0B56 for ; Wed, 18 Nov 2020 12:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 eB2fTDlaQP0s for ; Wed, 18 Nov 2020 12:05:53 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47D73A0858 for ; Wed, 18 Nov 2020 12:05:53 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id z24so614069qto.3 for ; Wed, 18 Nov 2020 12:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=hTpIBtzK0hU3JFHNrP52F+8/RxfC/kzh/Blv59UTfqw=; b=0EOpSwFYQDb8bK7517gXBqZ/mbFQCtg5F2w3lCY40SRFNCou53F+vRDFkdhEpwq1hg qUTp0uRKS8ZPGO8YCpOha0+40wIFrbHPxVkmEqapnKv3NGfANuKtk02UYDJdOAI7N179 wlFWuvZ/V/6+s1SIPk+50mObuvxjOm4qaoQeg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=hTpIBtzK0hU3JFHNrP52F+8/RxfC/kzh/Blv59UTfqw=; b=Ly+/XKAn5+xtYkznoOSWGlc3Bx7frALLVzfu7sozyyjKL/NH7KPQJhJAZLrKe3HZoe 84jASi2c9OAby5GGC1PYpACG4VTD3D2DiVoILZA61nKZr7zmVDfSjJ1WNSfHyXJBzR6M +HvoISznMevTf34hLfKGtjggqoRd6lHFnL9LFIHU5aY7WZf/1AjbyfPzN2qqUadOn3+e sDBl4udU3l4RBWQYIxlxS3qlpuIl6sH2jWzphcJFvb5bP2c0s3f5rJq7jtDY/NxWqan/ 9Vu3jRz0WNfvX0FI2+XTUbW1Ft9UcBm+mekQywDeelWd2zXiBm+vMuaKDQb/+y1vTBeC YjbQ== X-Gm-Message-State: AOAM530oqIQ6BXe4MCjTDG4e/oA0XvV27UZ5+7PmllmlqFrgS3ZiB5OZ PsCfUieqWfaI/tRl5WNvMjq29g== X-Google-Smtp-Source: ABdhPJx70ydy+mv9bHIkO4nzMMWhrqHfgrXjaL8vSCtsUaMXC6A9oaLD+rsTTiIG6cjluZUBHpvupg== X-Received: by 2002:ac8:5351:: with SMTP id d17mr6598298qto.235.1605729952379; Wed, 18 Nov 2020 12:05:52 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id j63sm17207726qke.67.2020.11.18.12.05.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 12:05:51 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 15:05:51 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688556751_185071937" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 20:05:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688556751_185071937 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable We need it standardized so that multiple parties =E2=80=93 all the RP=E2=80=99s, all th= e CA=E2=80=99s and all the customers =E2=80=93 have common expectations. [CW] We do not need =E2=80=9CMUST NOT process when critical=E2=80=9D with regard to thi= s, which is the point I chimed in on. Do you agree with that? On the bigger = points, as noted, I agree with others that absence of AIA and CRL DP is suff= icient. I could see where one might want to write a few words on what absenc= e of those extensions means but don=E2=80=99t see the need for another extension. --B_3688556751_185071937 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

We need it standardized so that multiple p= arties =E2=80=93 all the RP=E2=80=99s, all the CA=E2=80=99s and all the customers =E2=80=93 have com= mon expectations.

[CW] We do not need =E2=80=9CMU= ST NOT process when critical=E2=80=9D with regard to this, which is the point I ch= imed in on. Do you agree with that? On the bigger points, as noted, I agree = with others that absence of AIA and CRL DP is sufficient. I could see where = one might want to write a few words on what absence of those extensions mean= s but don=E2=80=99t see the need for another extension.

--B_3688556751_185071937-- From nobody Wed Nov 18 12:09:33 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813763A0B6B for ; Wed, 18 Nov 2020 12:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 eQQqdj6tMEcq for ; Wed, 18 Nov 2020 12:09:30 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C823A0B62 for ; Wed, 18 Nov 2020 12:09:29 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AIK5Njt011815; Wed, 18 Nov 2020 20:09:20 GMT 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=2b+4jh+kWq6p43TdQGJaLnYzU89+GHvkksLrgjrIhzc=; b=ImspxCzF+snP+4zqny/JzoXdWqKEiUigf1CWn7KiOfyGiz2m+8ytnLmDdLj/nEnFauF8 wJSl6P1uh4lX6pjprq/7OfKNMhqKYk1hUUZNWrP0dE9lLz1IfXj1bAn6WtAlw5xHYF9/ 1KRgnnh/I5Hhmnff0Q8OFX/3zE3cXR3jcCS72iS1nZVL30hG8JWULEjN1w8Cku1xvMAQ Kf18DAtOnm1/sHda6Q6YCu4yaAYZl26eqNCQViEEOiwOuCbt8KRTxWlHXd3lnggxWkhy JjoRyoErXyByCSFInHkKtcHPZc9VpF+fm/fZN8Z8u38J7kRYN1JeKxtMKx8B8qOYMETv 7A== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 34w7v0xk69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 20:09:20 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIK4EtQ020469; Wed, 18 Nov 2020 15:09:19 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint4.akamai.com with ESMTP id 34tbf3616e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 15:09:19 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 14:09:18 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 14:09:18 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0AAAqlRoD//60iAA== Date: Wed, 18 Nov 2020 20:09:18 +0000 Message-ID: <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> In-Reply-To: <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_405A0031CD094A9781DB0B44B45A45C5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=761 bulkscore=0 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=678 spamscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180140 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 20:09:32 -0000 --_000_405A0031CD094A9781DB0B44B45A45C5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQ1ddIFdlIGRvIG5vdCBuZWVkIOKAnE1VU1QgTk9UIHByb2Nlc3Mgd2hlbiBjcml0aWNh bOKAnSB3aXRoIHJlZ2FyZCB0byB0aGlzLCB3aGljaCBpcyB0aGUgcG9pbnQgSSBjaGltZWQgaW4g b24uIERvIHlvdSBhZ3JlZSB3aXRoIHRoYXQ/IE9uIHRoZSBiaWdnZXIgcG9pbnRzLCBhcyBub3Rl ZCwgSSBhZ3JlZSB3aXRoIG90aGVycyB0aGF0IGFic2VuY2Ugb2YgQUlBIGFuZCBDUkwgRFAgaXMg c3VmZmljaWVudC4gSSBjb3VsZCBzZWUgd2hlcmUgb25lIG1pZ2h0IHdhbnQgdG8gd3JpdGUgYSBm ZXcgd29yZHMgb24gd2hhdCBhYnNlbmNlIG9mIHRob3NlIGV4dGVuc2lvbnMgbWVhbnMgYnV0IGRv buKAmXQgc2VlIHRoZSBuZWVkIGZvciBhbm90aGVyIGV4dGVuc2lvbi4NCg0KSeKAmW0gd2lsbGlu ZyB0byBsZWF2ZSB0aGF0IHRvIHdvcmRzbWl0aGluZyBuZWdvdGlhdGlvbi4gIEhvdyBhYm91dCBT SE9VTEQgTk9UID8gIEJ1dCBJIGRvbuKAmXQgY2FyZSBncmVhdGx5Lg0KDQpXZSBzZWUgQ0HigJlz IGluIHB1YmxpYyB1c2UgdGhhdCBkbyBub3QgcG9wdWxhdGUgYWxsIGNlcnRpZmljYXRlcyB3aXRo IEFJQSBpbmZvcm1hdGlvbiwgc28gdGhlIGFic2VuY2Ugb2YgdGhhdCBpbmZvIGlzIG5vdCBzdWZm aWNpZW50LiAgV2UgbmVlZCBhIHBvc2l0aXZlIHNpZ25hbC4NCg== --_000_405A0031CD094A9781DB0B44B45A45C5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7D4E418968B0B64B80EA350EFE26F23A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEyNDc4NjQzNDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTE1MzQwMjk1MTggLTE3NzA0NTY0ODggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+Q1ddIFdlIGRv IG5vdCBuZWVkIOKAnE1VU1QgTk9UIHByb2Nlc3Mgd2hlbiBjcml0aWNhbOKAnSB3aXRoIHJlZ2Fy ZCB0byB0aGlzLCB3aGljaCBpcyB0aGUgcG9pbnQgSSBjaGltZWQgaW4gb24uIERvIHlvdSBhZ3Jl ZSB3aXRoIHRoYXQ/IE9uIHRoZSBiaWdnZXIgcG9pbnRzLCBhcyBub3RlZCwgSSBhZ3JlZSB3aXRo IG90aGVycw0KIHRoYXQgYWJzZW5jZSBvZiBBSUEgYW5kIENSTCBEUCBpcyBzdWZmaWNpZW50LiBJ IGNvdWxkIHNlZSB3aGVyZSBvbmUgbWlnaHQgd2FudCB0byB3cml0ZSBhIGZldyB3b3JkcyBvbiB3 aGF0IGFic2VuY2Ugb2YgdGhvc2UgZXh0ZW5zaW9ucyBtZWFucyBidXQgZG9u4oCZdCBzZWUgdGhl IG5lZWQgZm9yIGFub3RoZXIgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5J4oCZbSB3aWxsaW5nIHRvIGxlYXZlIHRoYXQgdG8gd29yZHNtaXRoaW5nIG5lZ290aWF0aW9u LiZuYnNwOyBIb3cgYWJvdXQgU0hPVUxEIE5PVCA/Jm5ic3A7IEJ1dCBJIGRvbuKAmXQgY2FyZSBn cmVhdGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBzZWUgQ0HigJlzIGluIHB1YmxpYyB1 c2UgdGhhdCBkbyBub3QgcG9wdWxhdGUgYWxsIGNlcnRpZmljYXRlcyB3aXRoIEFJQSBpbmZvcm1h dGlvbiwgc28gdGhlIGFic2VuY2Ugb2YgdGhhdCBpbmZvIGlzIG5vdCBzdWZmaWNpZW50LiZuYnNw OyBXZSBuZWVkIGEgcG9zaXRpdmUgc2lnbmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_405A0031CD094A9781DB0B44B45A45C5akamaicom_-- From nobody Wed Nov 18 12:24:12 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987B3A0BAB for ; Wed, 18 Nov 2020 12:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 aLyADWhg4ode for ; Wed, 18 Nov 2020 12:24:08 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 559E63A0BF1 for ; Wed, 18 Nov 2020 12:24:07 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id z24so661661qto.3 for ; Wed, 18 Nov 2020 12:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=OXWqky4XCLaonPggMOh0dgtifv/tPAJZdgIbAsGTSGA=; b=oPh5/1bBp8CkTsUa4htMhsGxk8jTRQgnxrGgImEKIlJ3C2AA0WCE0Y9wJ33mZLAtyW fhDSiv1rOjQ+p0IahOCHjEGvXrZ3tlqsOu3fGm8zrgeA/tyuJ8S5RnHhT8bsLyZx3AB7 1rfF3MPX5OiLS4SCVwBdVs/JOWObFmFV/+8+U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=OXWqky4XCLaonPggMOh0dgtifv/tPAJZdgIbAsGTSGA=; b=O2kZElkDZtNyPgSPQORXkFzcBETCbETvYU+cGe/R+JCHQI5rA5wiM+SX590hHByEJq OR10Shmni3z1LAjCLMOuB1KGUNGlbgxMEfWPYrGV7spDuYMP18tPRzxX9f6Z6keS/j6N ib9QxX2NQvU9TqqAUnjrD0hr7iXXFGZXfoBVNY1WulTpGeR3qliHKLxQx2yvRKYD2ef9 3/rlzrHpLYa/xNRV8vEL248oyG25YDipEX+nzOjnCZBLsg7XebFtfVCdXffyQDkObqYE khbOlrFBy70u+dBQblEjelgdFzvRRVpqTP5Z+L42KtBwcuDuDsT+2TDpy9s73C11yZQc HY/w== X-Gm-Message-State: AOAM530bBt5IQK8jSGfqWEzi6CO8GYmro2ahrHWRogCiCFQVEMJeiPi5 tizlLL02RZs80l3FZJs2CmoWAQ== X-Google-Smtp-Source: ABdhPJyLnJQv7i041dAf+7pKmhb8ehHqW+eGzWZAJincBV+1ngGOh/J4JijipZr1uGAxHlWT9bjwAg== X-Received: by 2002:aed:3263:: with SMTP id y90mr6152659qtd.196.1605731047073; Wed, 18 Nov 2020 12:24:07 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id 7sm16606298qko.106.2020.11.18.12.24.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 12:24:06 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 15:24:06 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> In-Reply-To: <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688557846_380866691" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 20:24:10 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688557846_380866691 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99m willing to leave that to wordsmithing negotiation. How about SHOULD = NOT ? But I don=E2=80=99t care greatly. =20 We see CA=E2=80=99s in public use that do not populate all certificates with AIA = information, so the absence of that info is not sufficient. We need a posit= ive signal. =20 [CW] This has now veered back into discussion that has already taken place.= The earlier notes requested standards language. The proposed standards lang= uage quickly arrived at a point where it didn=E2=80=99t make sense (i.e., telling = me I must or should not do something while conceding I can do what I want). = Aside from the difficulty of the meaning of critical, the proposed standards= language should address how the feature is introduced and what absence of t= he positive signal means in a certificate without AIA or CRL DP. To some ext= ent this is kind of like the introduction of basic constraints. Maybe this r= equires X.509 v4:-) --B_3688557846_380866691 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I=E2=80=99m willing to leave that to wordsmithin= g negotiation.  How about SHOULD NOT ?  But I don=E2=80=99t care greatly= .

 

W= e see CA=E2=80=99s in public use that do not populate all certificates with AIA in= formation, so the absence of that info is not sufficient.  We need a po= sitive signal.

 

[CW] This has now veered back into discussion that has already t= aken place. The earlier notes requested standards language. The proposed sta= ndards language quickly arrived at a point where it didn=E2=80=99t make sense (i.e= ., telling me I must or should not do something while conceding I can do wha= t I want). Aside from the difficulty of the meaning of critical, the propose= d standards language should address how the feature is introduced and what a= bsence of the positive signal means in a certificate without AIA or CRL DP. = To some extent this is kind of like the introduction of basic constraints. M= aybe this requires X.509 v4:-)

--B_3688557846_380866691-- From nobody Wed Nov 18 12:27:59 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8513A0BF1 for ; Wed, 18 Nov 2020 12:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tC0VMzT5LL1N for ; Wed, 18 Nov 2020 12:27:57 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E303B3A02C1 for ; Wed, 18 Nov 2020 12:27:56 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AIKLN0o007537; Wed, 18 Nov 2020 20:27:54 GMT 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=aM/3TODGJyZjmoK+XkJvo3qdQyJSybf/NGwwPikZU6Q=; b=W0HQUkQGDRnIhygCLWEHQWJHu07UIwnvwwep0z9dXuFj90vfYeX+kYIQvkHBR6lNmhQE xKOjwtcI+KH62WETlsmMlN81brlSRzErKuGYtnFtahC7Id+D8q6mPaEuT1Izj1a77N1r yfIEzXl5JY491QcYYToiryv27gBntJM+TaRLIupOJaa877NzNhY1p2K4wNmemH23NzP0 KQ6f9XuECEI5xI9oBTTMWsUlE/gD+NQnhqpVFafVMx+d0kXmBJF9B5fO2POy8of4rGo1 CrzQlIeNOPexKhdjX7g0rr3H7TbkkfJ3hYNqBNeUVW7coHrKedNkzNlS/Vtviiw7gPiN Rw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 34w7v0y2gp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 20:27:54 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIKKohj009212; Wed, 18 Nov 2020 15:27:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint6.akamai.com with ESMTP id 34tbf2rvw1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 15:27:53 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 14:27:52 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 14:27:52 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0AAAqlRoD//60iAIAAV/cA//+tOQA= Date: Wed, 18 Nov 2020 20:27:51 +0000 Message-ID: <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> In-Reply-To: <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_6E12311CB0144319BA1208E18E2309F7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=914 mlxscore=0 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180141 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 phishscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=830 spamscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180141 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.61) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint6 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 20:27:58 -0000 --_000_6E12311CB0144319BA1208E18E2309F7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkNXXSBUaGlzIGhhcyBub3cgdmVlcmVkIGJhY2sgaW50byBkaXNjdXNzaW9uIHRoYXQgaGFzIGFs cmVhZHkgdGFrZW4gcGxhY2UuIFRoZSBlYXJsaWVyIG5vdGVzIHJlcXVlc3RlZCBzdGFuZGFyZHMg bGFuZ3VhZ2UuIFRoZSBwcm9wb3NlZCBzdGFuZGFyZHMgbGFuZ3VhZ2UgcXVpY2tseSBhcnJpdmVk IGF0IGEgcG9pbnQgd2hlcmUgaXQgZGlkbuKAmXQgbWFrZQ0KDQpJIHdhcyB0cnlpbmcgdG8gYmUg YWNjb21tb2RhdGluZyBhbmQgSSBndWVzcyBJIHNob3VsZCBub3QgaGF2ZSBkb25lIHNvLg0KDQpJ IHByZWZlciB0aGUgbGFuZ3VhZ2UgSSBmaXJzdCBwcm9wb3NlZC4NCg0K --_000_6E12311CB0144319BA1208E18E2309F7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwvYj5DV10gVGhpcyBoYXMgbm93IHZlZXJlZCBi YWNrIGludG8gZGlzY3Vzc2lvbiB0aGF0IGhhcyBhbHJlYWR5IHRha2VuIHBsYWNlLiBUaGUgZWFy bGllciBub3RlcyByZXF1ZXN0ZWQgc3RhbmRhcmRzIGxhbmd1YWdlLiBUaGUgcHJvcG9zZWQgc3Rh bmRhcmRzIGxhbmd1YWdlIHF1aWNrbHkgYXJyaXZlZCBhdCBhIHBvaW50IHdoZXJlIGl0DQogZGlk buKAmXQgbWFrZSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgdHJ5aW5nIHRvIGJlIGFj Y29tbW9kYXRpbmcgYW5kIEkgZ3Vlc3MgSSBzaG91bGQgbm90IGhhdmUgZG9uZSBzby48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBwcmVmZXIgdGhlIGxhbmd1YWdlIEkgZmlyc3QgcHJvcG9zZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6E12311CB0144319BA1208E18E2309F7akamaicom_-- From nobody Wed Nov 18 13:55:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7483A0D76 for ; Wed, 18 Nov 2020 13:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 S4Iq6zc-fawB for ; Wed, 18 Nov 2020 13:55:20 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 61D993A0A3D for ; Wed, 18 Nov 2020 13:55:20 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id q5so3418375qkc.12 for ; Wed, 18 Nov 2020 13:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=VJDFmCeysCTM9YxcjqisDyTI9ChaVapTkD03LUUFPuk=; b=eQiOTZAty5SFJMQ31DQ1B6ZbVfmBPk6sxueAwcj/Kz1S6xKgYvSlDoNR0TOkQPBO3o pOH2oTZWTqWlo/6BZNkTX2jDMkvYeMsv92yTN2PZxBPtdxlPsSAXFAh0I1pVdEJbxKHV QMMMvzs23FoUpmPolsZDLHjCUrAlzyKxux2m8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=VJDFmCeysCTM9YxcjqisDyTI9ChaVapTkD03LUUFPuk=; b=Saes66gW/hYznyZIRsqr4vZijWvWr5TSp1iGaensQcwPg3vbm1EYEpuf6JaPPQJoe9 QkZTRbAMNUndAxByVygAZmr4Vhmh/0flSRo7dWYKBCh3E+t6/vPuTGfnuiFn4R+fuHTk MXO0WgUwAoqdY2NB7rUlyc34bu5awRRJNMQg648vX+LjUfFYOAzISdDffqSk816AGZ/E qTPZGKAV8F6GwIcdIOJDDRGyvSW1UnpnaVvRwa2Ik9hLOshU2fUEOlmbwhe4gKFA1BjR j4MqguALdBOyotHQRewF8EQkHCCoOj/k3UKpBM0TduaAFuxo03QW+Pzx0P5t2iCTTFak RIMw== X-Gm-Message-State: AOAM531SelXoZg3jHZHmgMqhqlppo6KQrZFTOrBqYa1+cixbNgl7LLiF pHQP+pacojkU/h/My16LMfdOoeQfyWjpOHug X-Google-Smtp-Source: ABdhPJwUuVl3PygZsVEKMD+uA66ev9q+q8/d4jzxvvBFxLqzkBbmNhR6IbCcHaDDtaT0Eph1d8m+DA== X-Received: by 2002:a37:9a43:: with SMTP id c64mr7575079qke.223.1605736519263; Wed, 18 Nov 2020 13:55:19 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id c12sm16262309qtx.54.2020.11.18.13.55.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 13:55:18 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Wed, 18 Nov 2020 16:55:17 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Message-ID: Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> In-Reply-To: <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688563317_446182231" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 21:55:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688563317_446182231 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I was trying to be accommodating and I guess I should not have done so. =20 I prefer the language I first proposed. [CW] How about instead of the positive statement that no revocation info is= available paired with absence of AIA and CRL DP, you define an extension th= at says =E2=80=9Cyes, I have revocation info but I=E2=80=99m not telling you where it is= in this certificate=E2=80=9D for the CAs that follow that particular practice? Th= at would leave absence of AIA and CRL DP with the semantics already suggeste= d by others. =20 --B_3688563317_446182231 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I was trying to be accommodating and I gue= ss I should not have done so.

 

I prefer the language I first proposed.

[CW] How about instead of the positive statement tha= t no revocation info is available paired with absence of AIA and CRL DP, you= define an extension that says =E2=80=9Cyes, I have revocation info but I=E2=80=99m not = telling you where it is in this certificate=E2=80=9D for the CAs that follow that = particular practice? That would leave absence of AIA and CRL DP with the sem= antics already suggested by others.

 <= o:p>

--B_3688563317_446182231-- From nobody Wed Nov 18 14:01:20 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DA73A0D9A for ; Wed, 18 Nov 2020 14:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SxcHsqxFdYEy for ; Wed, 18 Nov 2020 14:01:17 -0800 (PST) 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 EBF713A0D98 for ; Wed, 18 Nov 2020 14:01:17 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AILvp1E028109; Wed, 18 Nov 2020 22:01:11 GMT 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=A57IA4GcFxk/iDf8lyenxZIzI0gi5KMoycVRZGarjuE=; b=bQPN9Rk47TrkPWGCW5xwVKpwvBVXenEQPczcVpMzEU1O9TbgOiTltyCcUFmE7Za7ymrw ssBHLHNCzAlgX3jlpdqCaOL93CyF9vipIem3N2to6/C5B8HFBRKFAxmrvgoAU6Iv8IkN tb7cVlAgY/wbNdCA4IbusW1n2ykHW925puTDS+xAtxsb9ZqZYGrrvuL1PkST++Cm+eeW nLApQWbiQd8skRZfSJhekt9Jbs4lBMoiOMHKvxAiKbXZ7hDfEpXC922aG47Dj/62vPcC uYw2YxteZEbyqMQVjM8SZOcqdQtgQ9gstmzUIwSsAZ4SmVGr08h2qTIReanDBN/2AHgc 0w== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34w7v02r9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 22:01:11 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AILo2J2006117; Wed, 18 Nov 2020 17:01:10 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint7.akamai.com with ESMTP id 34tbf36nu3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 17:01:10 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 16:01:09 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 16:01:09 -0600 From: "Salz, Rich" To: Carl Wallace , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0AAAqlRoD//60iAIAAV/cA//+tOQCAAGxBgP//rc+A Date: Wed, 18 Nov 2020 22:01:08 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_CACDC18D30454BA0A266A7BBA0115EA5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=850 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=771 malwarescore=0 impostorscore=0 adultscore=0 mlxscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0 bulkscore=0 phishscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180150 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 22:01:19 -0000 --_000_CACDC18D30454BA0A266A7BBA0115EA5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGF0IHdvdWxkIGxlYXZlIGFic2VuY2Ugb2YgQUlBIGFuZCBDUkwgRFAgd2l0aCB0aGUgc2Vt YW50aWNzIGFscmVhZHkgc3VnZ2VzdGVkIGJ5IG90aGVycy4NCg0KRXhjZXB0IHRoYXQgdGhvc2Ug c2VtYW50aWNzIGJlaW5nIHN1Z2dlc3RlZCBkb27igJl0IGhvbGQgdG8gYmUgdHJ1ZSBpbiBvdXIg ZXhwZXJpZW5jZS4NCg== --_000_CACDC18D30454BA0A266A7BBA0115EA5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <475116BE0CDC9B4791458123A6409566@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwvYj4gVGhhdCB3b3VsZCBsZWF2ZSBhYnNlbmNl IG9mIEFJQSBhbmQgQ1JMIERQIHdpdGggdGhlIHNlbWFudGljcyBhbHJlYWR5IHN1Z2dlc3RlZCBi eSBvdGhlcnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4Y2VwdCB0aGF0IHRob3NlIHNlbWFu dGljcyBiZWluZyBzdWdnZXN0ZWQgZG9u4oCZdCBob2xkIHRvIGJlIHRydWUgaW4gb3VyIGV4cGVy aWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CACDC18D30454BA0A266A7BBA0115EA5akamaicom_-- From nobody Wed Nov 18 14:07:48 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458BC3A0DC1 for ; Wed, 18 Nov 2020 14:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 fTpKPe87TNBd for ; Wed, 18 Nov 2020 14:07:44 -0800 (PST) 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 8FB9E3A0DAC for ; Wed, 18 Nov 2020 14:07:44 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AILwKMP006756; Wed, 18 Nov 2020 22:07:41 GMT 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=qds+7Edt1J0/enAAw5TquG8U4q/QEhlgLtMfuJpgjlw=; b=HNox1yFhSBHooJgbqSkNdLy3Zi2gPeSVm8PS0GEUikAvGYnVfgyHNekY/KS7ZySutyLg Q9uCNsd3gLp3uajC0YCikGTfypD1mzJv5L1bQFrKyLCAJHEhg5ucZxvcVQBDYGcb8mms fFNWOBPFMwCzXUSPCgVKWf3oe49V2UDTRlliUx0C8CREkavdw8J2Oh8xfhVvjmsLu89m 0zLm0erhzk/VhqHpFOCOqseMFFyCDN/yLpEsWXlR2If8YUKzPnkCeuDubGMUfm0nw+5/ kIqRTn95/ZoIPMj4f+kCVu9rSryoL2I0RFj7rRefZ8TXHUpP2g/LigehDoLgw4A1N2FB 3g== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34w7r9kb5c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 22:07:40 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AIM4WxT000587; Wed, 18 Nov 2020 17:07:40 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 34tbf2pm0u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 17:07:39 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 16:07:39 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 16:07:39 -0600 From: "Salz, Rich" To: "Salz, Rich" , Carl Wallace , Ryan Sleevi , "Mike Ounsworth" CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0AAAqlRoD//60iAIAAV/cA//+tOQCAAGxBgP//rc+AgAAB0YA= Date: Wed, 18 Nov 2020 22:07:37 +0000 Message-ID: <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_5A0BF428BFD249C99D1F16AEDA69ADB5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxlogscore=850 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180151 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_08:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 impostorscore=0 mlxscore=0 mlxlogscore=767 lowpriorityscore=0 clxscore=1015 bulkscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011180150 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 22:07:46 -0000 --_000_5A0BF428BFD249C99D1F16AEDA69ADB5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhhdCB3b3VsZCBsZWF2ZSBhYnNlbmNlIG9mIEFJQSBhbmQgQ1JMIERQIHdpdGggdGhlIHNl bWFudGljcyBhbHJlYWR5IHN1Z2dlc3RlZCBieSBvdGhlcnMuDQoNCg0KICAqICAgRXhjZXB0IHRo YXQgdGhvc2Ugc2VtYW50aWNzIGJlaW5nIHN1Z2dlc3RlZCBkb27igJl0IGhvbGQgdG8gYmUgdHJ1 ZSBpbiBvdXIgZXhwZXJpZW5jZS4NCg0KRm9yIGV4YW1wbGUsIGEgcm91Z2ggY291bnQgWzFdIHNo b3dzIDcxLDAwMCBzdWNoIGNlcnRzLg0KDQpbMV0gaHR0cHM6Ly9jZW5zeXMuaW8vY2VydGlmaWNh dGVzP3E9emxpbnQubGludHMuZV9zdWJfY2FfYWlhX2RvZXNfbm90X2NvbnRhaW5fb2NzcF91cmwl M0ErdHJ1ZQ0KDQo= --_000_5A0BF428BFD249C99D1F16AEDA69ADB5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1BD68E8FDCABAE4F9BB8916012F3D090@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTM1Mjg4NDg7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04MDczMDU2 OCAxMDMyNzcwNjU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2 ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jmd0Ozwvc3Bhbj48L2I+IFRoYXQgd291bGQgbGVhdmUgYWJzZW5jZSBvZiBBSUEgYW5k IENSTCBEUCB3aXRoIHRoZSBzZW1hbnRpY3MgYWxyZWFkeSBzdWdnZXN0ZWQgYnkgb3RoZXJzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+RXhjZXB0IHRoYXQgdGhvc2Ugc2VtYW50aWNzIGJlaW5nIHN1Z2dlc3RlZCBkb27igJl0 IGhvbGQgdG8gYmUgdHJ1ZSBpbiBvdXIgZXhwZXJpZW5jZS48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIGV4YW1wbGUsIGEgcm91Z2ggY291bnQgWzFdIHNob3dzIDcxLDAwMCBzdWNo IGNlcnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0gPGEgaHJlZj0iaHR0cHM6Ly9jZW5z eXMuaW8vY2VydGlmaWNhdGVzP3E9emxpbnQubGludHMuZV9zdWJfY2FfYWlhX2RvZXNfbm90X2Nv bnRhaW5fb2NzcF91cmwlM0EmIzQzO3RydWUiPg0KaHR0cHM6Ly9jZW5zeXMuaW8vY2VydGlmaWNh dGVzP3E9emxpbnQubGludHMuZV9zdWJfY2FfYWlhX2RvZXNfbm90X2NvbnRhaW5fb2NzcF91cmwl M0EmIzQzO3RydWU8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5A0BF428BFD249C99D1F16AEDA69ADB5akamaicom_-- From nobody Wed Nov 18 14:13:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED493A07DE for ; Wed, 18 Nov 2020 14:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 gXT2vFHZiffA for ; Wed, 18 Nov 2020 14:13:51 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 A41E33A0EA8 for ; Wed, 18 Nov 2020 14:13:27 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id g19so1897932qvy.2 for ; Wed, 18 Nov 2020 14:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=68kgwvXdjqUvq3f+MderfAw7KY5Q2/T/nPeJ8CcgVcg=; b=lwkGyPcnwqs0BvpYr8XD1aTjc5OvlIc/Sv7D4c2+qMlzbaM+qwmATd8EulMUnSoS9U JZK6jZgxnlcOo2d5K8Z4r7Gc+lf3k7z94YZnZX8jiL29jaCfhef95Usx/Z3aeoviyOad gSbcotX/5Dzo3e8Sg0mpU0VsBpq+Cfzc8mggM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=68kgwvXdjqUvq3f+MderfAw7KY5Q2/T/nPeJ8CcgVcg=; b=YZsQhouuVH+cvGsSeAQBEYUMtoxaNWX+xGB6WXcva5Zv9rGKE9T548nHgROYgDsTvQ 5/k0S1vGTuFu4v4+1dGNg7AHunk7XQ9pExhw/xLXHCm98MmNNI3xTXYMiCQ+Wde6EWQb QYS4bKJpOrvYgvutFP5ta80YpTf+BmOz5mpyYXDlK4vGkMs9pheADtLSQ4pB0d+XYJvs rorAh0q2G2Q2NXgkHiiFl84ZtQDAxtDV0TYoRar41939L7z18RTg7S8VkXy/4FlielVJ AJqQu2c9mdWFHhlEp9CsgekHocOReCLT95VUQ7wkyfiY/wiAG4q4swBERhBwdlD88SoO KIuw== X-Gm-Message-State: AOAM530Eigr7Xr6Wujv7urS5dDGI4i1a82lOh/ga3txz+OI5V35AYKEm 2qPN7XmxZYCOxmFugToH8CyVHc4lFWp7gw== X-Google-Smtp-Source: ABdhPJzju061VbQyArmfk/SdNLU9Gv3K4lIw+FK0mCuHnlKqVGPaqgnMOckXUVJTqODTQRAsg81dIw== X-Received: by 2002:a0c:f607:: with SMTP id r7mr7335822qvm.47.1605737606497; Wed, 18 Nov 2020 14:13:26 -0800 (PST) Received: from ?IPv6:2600:1003:b127:ad93:991a:a23d:f189:a132? ([2600:1003:b127:ad93:991a:a23d:f189:a132]) by smtp.gmail.com with ESMTPSA id f130sm16050660qke.30.2020.11.18.14.13.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 14:13:25 -0800 (PST) Content-Type: multipart/signed; boundary=Apple-Mail-8A19FC62-603A-4F61-BE6A-C8BE85AD9571; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Carl Wallace Mime-Version: 1.0 (1.0) Date: Wed, 18 Nov 2020 17:13:24 -0500 Message-Id: <3668D483-F0A0-477F-B682-3E376B1079C1@redhoundsoftware.com> References: <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> Cc: "Salz, Rich" , Ryan Sleevi , Mike Ounsworth , LAMPS , Santosh Chokhani In-Reply-To: <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> To: "Salz, Rich" X-Mailer: iPhone Mail (17D50) Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 22:13:53 -0000 --Apple-Mail-8A19FC62-603A-4F61-BE6A-C8BE85AD9571 Content-Type: multipart/alternative; boundary=Apple-Mail-5508C17F-5794-428C-A285-6C04EEBAF7E0 Content-Transfer-Encoding: 7bit --Apple-Mail-5508C17F-5794-428C-A285-6C04EEBAF7E0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to offer a counter approach. I guess I shouldn=E2=80=99t have. I pre= fer to not have extension to restate that revocation info pointers are not p= rovided. Let=E2=80=99s leave it there.=20 > On Nov 18, 2020, at 5:07 PM, Salz, Rich wrote: >=20 > =EF=BB=BF > >> That would leave absence of AIA and CRL DP with the semantics already s= uggested by others. > =20 > Except that those semantics being suggested don=E2=80=99t hold to be true i= n our experience. > =20 > For example, a rough count [1] shows 71,000 such certs. > =20 > [1] https://censys.io/certificates?q=3Dzlint.lints.e_sub_ca_aia_does_not_c= ontain_ocsp_url%3A+true > =20 --Apple-Mail-5508C17F-5794-428C-A285-6C04EEBAF7E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I tried to offer a counter= approach. I guess I shouldn=E2=80=99t have. I prefer to not have extension t= o restate that revocation info pointers are not provided. Let=E2=80=99s leav= e it there. 

On Nov= 18, 2020, at 5:07 PM, Salz, Rich <rsalz@akamai.com> wrote:

Then I mistook your =E2=80=9CIF the extension is marked CRITICAL than relying parties MUST NOT use= such information=E2=80=9D as standards language to the contrary.

 

From: "Salz, Rich" <rsalz@akamai.com>
<= b>Date: Wednesday, November 18, 2020 at 2:33 PM
To: Carl Walla= ce <carl@redhoundsoftware.com>, Ryan Sleevi <ryan-ietf@sleevi.com&g= t;, Mike Ounsworth <Mike.Ounsworth@entrust.com>
Cc: LAMPS &l= t;spasm@ietf.org>, Santosh Chokhani <santosh.chokhani@gmail.com>Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension

 

=
  • [CW] It is none of the CA=E2=80=99s business i= f I elect to consider a certificate revoked.

 

Sure, you can do whatever ou= t of band processing you want.

=EF=BB=BF

>> That would leave absence o= f AIA and CRL DP with the semantics already suggested by others.<= /p>

 

  • Except that those semantics being suggested don=E2=80=99t hold to be tr= ue in our experience.

 

For example, a rough count [1] shows 71,000 such cert= s.

 

[1] https://censys.io/certificates?q=3Dzlint.lints.e_sub_ca_aia_does_not_contain= _ocsp_url%3A+true

 

= --Apple-Mail-5508C17F-5794-428C-A285-6C04EEBAF7E0-- --Apple-Mail-8A19FC62-603A-4F61-BE6A-C8BE85AD9571 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBSMw ggUfMIIEB6ADAgECAhBZMrqipFA0xBQBYS3sfSwuMA0GCSqGSIb3DQEBCwUAMIGWMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYD VQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MDExNDAwMDAwMFoXDTIyMDExMzIzNTk1 OVowKjEoMCYGCSqGSIb3DQEJARYZY2FybEByZWRob3VuZHNvZnR3YXJlLmNvbTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAMRQ9JmY9x5fdVFKr6ybg8FXCeiEHBKc+Y4M7cL+s42twbgz p3NFrL/0GUfipN5deChbToHYE42iofiTiMc2Ad59w/4JOO7+uLOXWyRrD2oUnLKWoMDwqLgWmIMw /mvG6IbFFk8U9iEFUuU1+kSwNN4PyanS8QVLtA52JAGf1sGZLaj6zTdhqwNa1wXxSCbxFCNvfhrS vJjWn31ipdiJs0f40nZJ8UhNeOJWZH9Dbh9jZDpQC7c6iEOn6XVfB8jyxsr1qAbvIO0XzOPu+fQw syE7vhJgwW4V2460121wBF/jGWSrlsnXS9pTfnWIhZTtDwoFvFeq+AIKaoSJUEK1LhcCAwEAAaOC AdIwggHOMB8GA1UdIwQYMBaAFAnA8vwL2pTbX/4r36iZQs/J4K0AMB0GA1UdDgQWBBSfuc4jxwXs bmzzYT8rz9ImCv7uIjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcC ARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5z ZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNybDCBigYIKwYBBQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29t L1NlY3RpZ29SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsG AQUFBzABhhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAkBgNVHREEHTAbgRljYXJsQHJlZGhvdW5k c29mdHdhcmUuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQCH9YcWFC253MDrnoyRWgyh0ifjHie1/vXg Ahbyq/jn/P3h2iRZrsCeOZoeDbxQ3rljxUnmMVbfAVb4Ao/oMHy+GNplTBfVO4ZuVhsQ01EX3yoH ai7UZ+4YdkXPMgyYj+jF8AAf7qr2RDlR7NNSGXla0LlDYTbCoasvMbeeTudwYIlig3DqRMZnB7zl L07gXfd7LNmO0kGck0fm6OekSmBXqH7/dinOIj+EHNUFf1qGHon0RYjVSvSD+I7z7RYkHSc0rOVh jvGNCSXPoLY6MMH8keCY0I7SDLj+CNL38ak9wXijFMufm9TrxRCEtNB4fuTk2Ipk8A5Dc2VmcEeD YggNMYIDxDCCA8ACAQEwgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UE AxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EC EFkyuqKkUDTEFAFhLex9LC4wDQYJYIZIAWUDBAIBBQCgggHpMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMTExODIyMTMyNFowLwYJKoZIhvcNAQkEMSIEIPXfHFoy OWxk6TLRZlmCl0R6E79SCYM5AtwjwczcW7bmMIG8BgkrBgEEAYI3EAQxga4wgaswgZYxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAW BgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEFkyuqKkUDTEFAFhLex9LC4wgb4GCyqGSIb3 DQEJEAILMYGuoIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNl Y3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBZMrqi pFA0xBQBYS3sfSwuMA0GCSqGSIb3DQEBAQUABIIBAGVDGVaoEFGk9iWwl9HbM4zd6ioYEykhjDLV KLk2M9+/n/haKYB07JOjAEFasuBeOFwZQKHXFSRdvRlfyVQRET7LthRzb9v4mX+9HifADRDRyffS V8yOrQwSbI+OkrHrql0yQWFpRfE/0ONAyr/rQ4Ypu0Vp1igr1QKsy35x1hRMtln3+nAKdMFbZgcm XhGuT253694NrrlAb9wt/4e2yGjJhHh02Hi4d5JZiNF7ZsevH1PO7HmrOq12DjN9BJ/IaH/jABfh SN1r8aTumJl1onhneRRl3TgztuxMtZw3ZZ6N2/sDZQGQ9LQJr6SpmuXFVRjTU251Lg1osUKCbRsk 1VsAAAAAAAA= --Apple-Mail-8A19FC62-603A-4F61-BE6A-C8BE85AD9571-- From nobody Wed Nov 18 18:18:37 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABF53A0953 for ; Wed, 18 Nov 2020 18:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=vWawgGf9; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=HCdvm+qe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mmwy1pAJm4SR for ; Wed, 18 Nov 2020 18:18:34 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E452F3A0954 for ; Wed, 18 Nov 2020 18:18:33 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605752311; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hcTCct3Ebf+Ls9vpp+CViayUwbh2f+tjkq4lo1YcI/M=; b=vWawgGf9f5BCFVjBeI8BAnJSlbEk3Splxh1h28GklVCUKxxe/VDK/U9J2LT7bwOem4Ine jUw5DoBNryAjoIzCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605752311; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=hcTCct3Ebf+Ls9vpp+CViayUwbh2f+tjkq4lo1YcI/M=; b=HCdvm+qeA1+L1DLIpb/eMeIU9DMmL6XCBhTpRZETFGbcT13JuFENmdEDGm8h5OKy1z91h lrh6/uJxfIXp4PeUBgV5pvgqao7WE9Jz3IFgJImVYD3Re7O2wOSui30KANUzt4GKwfeBqJa ow77EAM73WREd58+O5nKFES2W4O8Cw3UQmr+yDGrQovqYvfhlgCxqZbmQEwXv3eEGagMiGx Wkga490+2c8mAIMYAqn2n1Fl+BQ5PgSdEJt/TpF+VIgieaXU0b4mO8/PIvsOQvY5Uylc+47 93OECpeEso9QYwAV2Ene4W2ISPGs0qQFHduNTPIBMj7VxjR503aYmmWm4EYA== Received: from fifthhorseman.net (unknown [IPv6:2001:470:1f07:60d:f2de:f1ff:fec3:d109]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 19E1CF9A7; Wed, 18 Nov 2020 21:18:31 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id A30292090F; Wed, 18 Nov 2020 21:18:27 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , "Salz\, Rich" , Carl Wallace , Ryan Sleevi , Mike Ounsworth Cc: LAMPS , Santosh Chokhani In-Reply-To: <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 18 Nov 2020 21:18:26 -0500 Message-ID: <874klmay31.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:18:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2020-11-18 22:07:37 +0000, Salz, Rich wrote: >>> That would leave absence of AIA and CRL DP with the semantics already s= uggested by others. > > > * Except that those semantics being suggested don=E2=80=99t hold to b= e true in our experience. > > For example, a rough count [1] shows 71,000 such certs. > > [1] https://censys.io/certificates?q=3Dzlint.lints.e_sub_ca_aia_does_not_= contain_ocsp_url%3A+true These are intermediate CA certs that don't contain OCSP urls. the zlint label e_sub_ca_aia_does_not_contain_ocsp_url suggests a violation of Baseline Requirement: 7.1.2.2: "Subordinate CA certificates authorityInformationAccess extension must contain the HTTP URL of the issuing CA=E2=80=99s OCSP responder" So let's dig into the first example (in my view of the above list anyway), which is "Swisscom Rubin CA 1": https://censys.io/certificates/86053117868a2582946790714db09b2c84c46299fe00= 8bc96b1f60a8119855e2 it is issued by "Swisscom Root CA 1", a root CA trusted by Mozilla, Microsoft, and Apple: https://censys.io/certificates/21db20123660bb2ed418205da11ee7a85a65e2bc6e55= b5af7e7899c8a266d92e Assuming i'm understanding the censys data correctly, it looks like none of the immediate children of "Swisscom Root CA 1" have *any* OCSP responder URL listed. Maybe that means that this is a root CA that just doesn't run an OCSP responder? (it does offer a CRL, and all of the intermediates i looked at did point to that CRL) So this just means that these intermediate CA certs would be in violation of the baseline requirements, so maybe none of them would be acceptable as an intermediate CA if (for example) the relying party's local policy dictates that intermediate CA certificates should be rejcted if they violate BR 7.1.2.2. But the inclusion of an id-pkix-ocsp-nocheck extension wouldn't somehow make the certificate suddenly comply with BR 7.1.2.2, right? it would still be lacking an OCSP responder AIA, so this particular local policy wouldn't be affected by the presence (or absence) of the extension -- we've already got the information we need for it in the certificate itself. Is there an example of a real world local policy for relying parties that would make use of this field, then i'd like to know about it. If there isn't one, then i don't understand why we should promote a new extension. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7XV8wAKCRDEDyVUMvKB D+EFAP0Z2bEUuFDv7J6Hdl/dRwxRyGey38ZYIZz3xYGAKZkPQgD+KZT7qeMYOpgS c9gfkOZb10pQozT2D+gBpvRMeb1NdgI= =2bgW -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 18 18:18:42 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB13A3A0953 for ; Wed, 18 Nov 2020 18:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=cQ4ptP0y; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=zt4JsGWu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mgej2AKNmMtl for ; Wed, 18 Nov 2020 18:18:34 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8AFD3A0942 for ; Wed, 18 Nov 2020 18:18:33 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605752311; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TxogXAWQiGvlEsUWzicwE+zoIqg71ULYRyyX9IAkJz4=; b=cQ4ptP0yrqQkmdtZzyR20CR6/sTGBnYUQyFZlPQIrNAT+T7EjvtUc7wLuDruxakDXH7rP xzkOIZ8EZ8S7Yd4Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605752311; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=TxogXAWQiGvlEsUWzicwE+zoIqg71ULYRyyX9IAkJz4=; b=zt4JsGWuuupYLGs7tl+Y9/J3IDsnJfrqyEHClOL/qHmz+lg/j/djKsfLdYeSdzVVe9Xn4 c1Nny6FCInPpq9HQYzglofqVFHzg5tCuA2FbYGMv9h92A0+xGctWdJkA6RqS3VCnmic5FpK o3BuetBr4lEOKcRgNZTQAB+zspgLEWF322jFBtpYmw5666cjT6KiapoxX2RKP58QAUW8r2c mFAFjtcY/8koLSqYJag0jwLG/+148l/12K1kiKfDb9UtrFeSoYpPLp4egEYiEg5fJhaAi4s 00BKk3YexTlK7mHV/3J1fN1/TJ62mLZe7CycS4DhNIVPIvm7H2WBK0zw3nIA== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 522A7F9A5; Wed, 18 Nov 2020 21:18:30 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id F06032085B; Wed, 18 Nov 2020 20:52:15 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Ryan Sleevi , Mike Ounsworth Cc: LAMPS , Santosh Chokhani In-Reply-To: <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Wed, 18 Nov 2020 20:52:15 -0500 Message-ID: <877dqiazao.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:18:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rich-- On Wed 2020-11-18 19:04:30 +0000, Salz, Rich wrote: > If the extension is specified, then the CA indicates that revocation > information, such as OCSP or CRLs, will not be provided.=20 Thanks for trying to help me understand your use case here. I'm afraid i still don't get it -- or at least, i think i understand what might be happening in some RPs that have decided to look up revocation information someplace not specified in the cert. But i don't see why the choices of those RPs warrant introducing potential redundancy and inconsistency for *all* RPs, subscribers, and issuers. Doesn't the lack of OCSP and CRL location information in the certificate communicate the same information? > Relying parties are free to use and process any such information they > have available to them. Surely this is the case always, regardless of what's in the certificate. > IF the extension is marked CRITICAL than relying parties MUST NOT use > such information. This is not the semantics of criticality that i expect. I thought that marking an X.509 extension as critical meant "if you don't know how to interpret this extension, you MUST NOT accept this certificate". But if you *do* know how to interpret the extension, then the criticality of the extension is irrelevant; you are simply expected to take its semantics into account during your validation process. That is, "criticality" means "don't skip this bit just because you don't understand it: if you do, you risk getting burned". But maybe i've inherited this understanding of criticality from some other space (e.g. OpenPGP subpacket bit 7, see RFC 4880 =C2=A75.2.3.1), and maybe it's not a valid read of criticality for X.509v3. Are there examples where criticality actually alters the semantics of an X.509v3 extension for relying parties that *do* understand the extension? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7XPzwAKCRDEDyVUMvKB D2qbAP9Pu06TRYCBDp/4rVDalhyUhi4tfOsfMo4PX25xqGL6dQD+PRncueYR7Sxq RiP/8JebZXwCzYtYHYO2K7ttEZp5rQw= =30pm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 18 20:03:15 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2BB3A09EF for ; Wed, 18 Nov 2020 20:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hdGipC_W_DDX for ; Wed, 18 Nov 2020 20:03:13 -0800 (PST) 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 13BE63A09E0 for ; Wed, 18 Nov 2020 20:03:12 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AJ40Mvd000516; Thu, 19 Nov 2020 04:03:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=EwrINIZEoMHQaUJRX1VyKsx6/iLYZ1Eme3EGHlgWhgw=; b=MUJxjcl47i5r2IA8i5dJuQDX28Y1IPzqt3zj0c2h0UOq/jhtLOkdLn7xUGczy8khvtVy 5uloi0hRtTw0kriVe/MbnisZjNNJoC7U87IU/eWiHmk1A4OyxMgdaJbSAmKBxXGAb8c5 k5c85uN9k7wAAuI7Fs6cOwbU6KOq0jsFGZ0u1ZawHwQtORnaLrJURR+ugqxP5MdEdmvU SAYgV7qoPeIUBpoKYOi5RmKj39g3GCjhXENBCCMGnKL+GXklgvbq3N1xc1QGahmKnIk0 gw62odttrihQsBzG6XSjd+3xxs3WRYM2odO93g/g0AVZbFCDZNR5KMjoKzpX37c9GA2I Lw== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 34w7s8r19m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 04:03:07 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ3nrBl023604; Wed, 18 Nov 2020 23:03:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint7.akamai.com with ESMTP id 34tbf38bf4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 23:03:07 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 22:03:06 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 22:03:05 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Carl Wallace , Ryan Sleevi , "Mike Ounsworth" CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgABU9ID//7MgAIAAVncA//+sloCAAFffgP//rM0AAAqlRoD//60iAIAAV/cA//+tOQCAAGxBgP//rc+AgAAB0YCAAJnmAP//yWoA Date: Thu, 19 Nov 2020 04:03:04 +0000 Message-ID: <47F854A5-B48F-4238-9621-6E3511E53DBA@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> <874klmay31.fsf@fifthhorseman.net> In-Reply-To: <874klmay31.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_10:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=899 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190025 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_10:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=816 suspectscore=0 impostorscore=0 adultscore=0 clxscore=1011 phishscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190027 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 04:03:14 -0000 ICAgID4gWzFdIGh0dHBzOi8vY2Vuc3lzLmlvL2NlcnRpZmljYXRlcz9xPXpsaW50LmxpbnRzLmVf c3ViX2NhX2FpYV9kb2VzX25vdF9jb250YWluX29jc3BfdXJsJTNBK3RydWUNCg0KPiAgICBUaGVz ZSBhcmUgaW50ZXJtZWRpYXRlIENBIGNlcnRzIHRoYXQgZG9uJ3QgY29udGFpbiBPQ1NQIHVybHMu DQoNCkFsbCBvZiB0aGVtPyAgSSBjb3VsZG4ndCBmaWd1cmUgb3V0IGhvdyB0byBzYXkgImFuZCBu b3QgYSBDQSIuDQoNCg== From nobody Wed Nov 18 20:13:30 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CECC3A0A81 for ; Wed, 18 Nov 2020 20:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 qv-KA4iDYGYg for ; Wed, 18 Nov 2020 20:13:28 -0800 (PST) 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 528683A0A7E for ; Wed, 18 Nov 2020 20:13:28 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ48d9A013155; Thu, 19 Nov 2020 04:13:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+9wqQ7Gq6avElMiQDWQJS6xIQQ1BThX7GNNok4r7rcs=; b=nsrtSEhzTNaVJiqdd0kJ88HmY1Yqjv3US3uqXxl2CMZuowIVwnPm3mnnQAQQonyEym1/ QA85M0BFVFqDl11d7V1F9rpZR8Xlmw5MLpTofBj1K/xINFFNUkOHBsZ6Wssn+Om01PC2 OV9EoVNosdm2yLdN3RlPj7RmN2kLimKFJeyqdXb4S/9UOL7n/QM4JTq29FPmMdC3cQEV k0fkq/l/jJCtcELtxTHW5s8fS22hPuGsL+HwI2NK4HEktL/bB6O5dzYbKXgBhrxj7GJ/ zVQ70ixVwVYVvC4QMlYLfY/USzAIH8ODpUO2I6xHxRyVSsbEoS25R7a+q1g/OiktU6TH uQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34w7ra0hav-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 04:13:24 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ4BPR8017968; Wed, 18 Nov 2020 23:13:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint8.akamai.com with ESMTP id 34tbf2ga02-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Nov 2020 23:13:23 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 18 Nov 2020 22:13:22 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Wed, 18 Nov 2020 22:13:22 -0600 From: "Salz, Rich" To: Daniel Kahn Gillmor , Ryan Sleevi , Mike Ounsworth CC: LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgADFv4D//9NNAA== Date: Thu, 19 Nov 2020 04:13:21 +0000 Message-ID: <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> In-Reply-To: <877dqiazao.fsf@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <4179D32F705D354E864564DB5797CB98@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_10:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-18_10:2020-11-17, 2020-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 impostorscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 bulkscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190028 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 04:13:29 -0000 PiAgICBpIHN0aWxsIGRvbid0IGdldCBpdCAtLSBvciBhdCBsZWFzdCwgaSB0aGluayBpIHVuZGVy c3RhbmQgd2hhdCBtaWdodCBiZQ0KICAgIGhhcHBlbmluZyBpbiBzb21lIFJQcyB0aGF0IGhhdmUg ZGVjaWRlZCB0byBsb29rIHVwIHJldm9jYXRpb24NCiAgICBpbmZvcm1hdGlvbiBzb21lcGxhY2Ug bm90IHNwZWNpZmllZCBpbiB0aGUgY2VydC4NCg0KSWYgYWxsIG9yaWdpbnMgd2VyZSBhcyBpbmZv cm1lZCBhbmQgZGlsaWdlbnQgYXMgdGhvc2Ugb2YgdXMgaW4gdGhpcyBjb21tdW5pdHksIGl0IHdv dWxkIHByb2JhYmx5IG5vdCBiZSBuZWVkZWQuIEJ1dCB0aGV5IGFyZSBub3QsIGFuZCB3ZSBzZWUg b3JpZ2luIGNlcnRzIHdpdGhvdXQgT0NTUCBBSUEuIE9yIHBlb3BsZSBzYXkgIkkgZG9uJ3Qga25v dywgYXNrIHRoZSBDQSIgZXRjLg0KDQo+IEJ1dCBpIGRvbid0IHNlZSB3aHkNCiAgICB0aGUgY2hv aWNlcyBvZiB0aG9zZSBSUHMgd2FycmFudCBpbnRyb2R1Y2luZyBwb3RlbnRpYWwgcmVkdW5kYW5j eSBhbmQNCiAgICBpbmNvbnNpc3RlbmN5IGZvciAqYWxsKiBSUHMsIHN1YnNjcmliZXJzLCBhbmQg aXNzdWVycy4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBpbmNvbnNpc3RlbmN5IGFyZ3VtZW50 LiBBcmUgeW91IHNheWluZyB0aGF0IHRoZXJlIGFyZSBubyBlbmQtZW50aXR5IGNlcnRzIHVzZWQg aW4gVExTIHRoYXQgZG8gbm90IG1pc3Rha2VubHkgaGF2ZSBtaXNzaW5nIEFJQSBmaWVsZHM/ICAg QWxzbyBzZWUgbmV4dCBwYXJhZ3JhcGguDQoNCj4gICAgRG9lc24ndCB0aGUgbGFjayBvZiBPQ1NQ IGFuZCBDUkwgbG9jYXRpb24gaW5mb3JtYXRpb24gaW4gdGhlIGNlcnRpZmljYXRlDQogICAgY29t bXVuaWNhdGUgdGhlIHNhbWUgaW5mb3JtYXRpb24/DQoNCkkgZG8gbm90IHNlZSBhbnl0aGluZyBp biBSRkMgNTI4MCBzZWMgNC4yLjIuMSB0aGF0IHNheXMgdGhlIE9DU1AgQUlBIGlzIHRoZSAqb25s eSogcGxhY2Ugd2hlcmUgT0NTUCByZXNwb25kZXIgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGZvdW5k LiBUaGUgYXJndW1lbnQgdGhhdCBzb21lIGFyZSBtYWtpbmcgImlmIGl0J3Mgbm90IGluIHRoZSBP Q1NQIEFJQSB0aGVyZSBpcyBubyBPQ1NQIHJlc3BvbmRlciIgZG9lcyBub3Qgc2VlbSBzdXBwb3J0 ZWQgYnkgdGhlIHRleHQuIFBlcmhhcHMgSSBhbSBtaXNyZWFkaW5nIGl0LCBvciBzaG91bGQgbG9v ayB0byBlcnJhdGEgb3Igb3RoZXIgUkZDJ3MgLS0gcGxlYXNlIHBvaW50IG1lIHRvIHRoZW0uDQoN Cj4gICAgVGhhdCBpcywgImNyaXRpY2FsaXR5IiBtZWFucyAiZG9uJ3Qgc2tpcCB0aGlzIGJpdCBq dXN0IGJlY2F1c2UgeW91IGRvbid0DQogICAgdW5kZXJzdGFuZCBpdDogaWYgeW91IGRvLCB5b3Ug cmlzayBnZXR0aW5nIGJ1cm5lZCIuDQoNClllcywgeW91IGtpbmQgb2YgaGF2ZSB0byBzcXVpbnQg dG8gdHJlYXQgY3JpdGljYWxpdHkgYXMgSSBkZXNjcmliZWQgaXQuIE1heWJlIHNxdWludCBzbyBt dWNoIHlvdSBjYW4ndCBldmVuIHNlZSB0aGUgdGV4dCwgSSBhZG1pdCA6KQ0KDQoNCg== From nobody Wed Nov 18 20:44:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66F83A0C4D for ; Wed, 18 Nov 2020 20:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aw_Uu3jaqtfG for ; Wed, 18 Nov 2020 20:44:35 -0800 (PST) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 117E53A0C47 for ; Wed, 18 Nov 2020 20:44:35 -0800 (PST) Received: by mail-pg1-f170.google.com with SMTP id i13so3091875pgm.9 for ; Wed, 18 Nov 2020 20:44:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mv81Pg62HKm17zyc8UZXM3pd6neCdUwB4eHUsTm/XI8=; b=GmwVOuiU7CifDG1wFc5BWypTXQqPirAMGv+RcjPepOe3jOfL4MKqLRv9PnjpV8+ogT CD0E2VJVgGcc5JEDz5aNIlpZRtas1166kas9bInyXO2fvfT1PbbIzkn1vD+VK9UR09HH xGg9TL3IeORoeX/JD57Un9L2ogKBLR33xOGh5kJqrW2x2elYJvTudwOLAY2c2bd5CKv5 6oJi69k/w1dT051mkVg2bDKCxPiN21/Wq/azrGgF5udX8kRrcEfe9Ce+FNTPayjq7ASe Rxjjw8BoK9ADeyNswrYiG9/+k/b2wPgPUQlEgZay+DzkP86NeUOF347Tnf/tmW/D9YfE Kxmw== X-Gm-Message-State: AOAM5322OVPcZ24FvWIyTwh9e08w2cnP+CAOM8cFZDGF2AbpxZMbd0c+ juR3oBwUEmCllpPKQb1igOK/c0iBQwE= X-Google-Smtp-Source: ABdhPJzKaf7rlLqVnSnfqDIsBJbhKxmD2mbCZXf/rmhaRAJE0yh/EICVG6aePwrhsP1ypxp7xIxKHw== X-Received: by 2002:a17:90a:a81:: with SMTP id 1mr2341026pjw.165.1605761074082; Wed, 18 Nov 2020 20:44:34 -0800 (PST) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com. [209.85.210.179]) by smtp.gmail.com with ESMTPSA id 144sm28248451pfb.71.2020.11.18.20.44.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 20:44:33 -0800 (PST) Received: by mail-pf1-f179.google.com with SMTP id b63so3238189pfg.12 for ; Wed, 18 Nov 2020 20:44:33 -0800 (PST) X-Received: by 2002:a63:b07:: with SMTP id 7mr11895620pgl.364.1605761073120; Wed, 18 Nov 2020 20:44:33 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> In-Reply-To: <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> From: Ryan Sleevi Date: Wed, 18 Nov 2020 23:44:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Daniel Kahn Gillmor , Ryan Sleevi , Mike Ounsworth , LAMPS , Santosh Chokhani Content-Type: multipart/alternative; boundary="0000000000005b8b9c05b46e62cf" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 04:44:37 -0000 --0000000000005b8b9c05b46e62cf Content-Type: text/plain; charset="UTF-8" On Wed, Nov 18, 2020 at 11:13 PM Salz, Rich wrote: > I don't understand the inconsistency argument. Are you saying that there > are no end-entity certs used in TLS that do not mistakenly have missing AIA > fields? Also see next paragraph. > This seems an entirely orthogonal discussion? > > > Doesn't the lack of OCSP and CRL location information in the > certificate > communicate the same information? > > I do not see anything in RFC 5280 sec 4.2.2.1 that says the OCSP AIA is > the *only* place where OCSP responder information should be found. The > argument that some are making "if it's not in the OCSP AIA there is no OCSP > responder" does not seem supported by the text. Perhaps I am misreading it, > or should look to errata or other RFC's -- please point me to them. > I'm not sure if you're lumping me in that "some", but I've repeatedly acknowledged this scenario as being precisely why what you're proposing doesn't make sense. There are, in effect, three possible sources for OCSP information: 1. The AIA of the certificate 2. The Directory object associated with the DN of the certificate 3. Local Policy The absence of 1. is our first sign that the CA has decided not to provide OCSP information. 2 is just... not a thing in polite society, although I'm sure ITU-T adherents might suggest otherwise. So really, the source of that is 3. You gave one such illustration of 3, when you stated "In addition, an RP might have a global list of OCSP responder configured.". There, an RP has a local policy that (presumably) is some mapping of DN to OCSP URL, although strictly speaking, it could just be *one* OCSP URL (ah OCSP, how complex and fickle you are). Yet in that situation, we have an RP making a decision, independent of the CA, to unilaterally check OCSP. That is a local policy (mis)configuration, and if a local policy does this, then I fail to see why local policy would or should respect what the CA says. Now, if we assume this extension existed, then we also have to assume that the client will update to support this local policy, and apriori agree with the CA to make use of this extension to indicate such a scenario. That is, both local policy AND software must be changed to support this scenario. Yet, if that's our goal, we can accomplish the same thing without any software change on the RP side. Given that, in order for this extension to have any relevance in the presence of misconfigured local policy, the RP and the CA must agree out-of-band to use this extension, we have to acknowledge that the RP and the CA have some form of relationship. A CA can just as equally divide the "certs for which we provide no OCSP information for" and the "certs for which we do" into two separate subordinate hierarchies (that is, two different issuer DNs). Then our plucky, but misguided, local RP, they simply have to omit providing a URL for the DN of the CA that doesn't provide revocation information. Put differently, this mess only exists because of 2 or 3, and cannot exist because of 1 (at least, as presently described). Because both 2 and 3 are matters of local policy, any undesirable effect is self-inflicted, but equally, any intended or desired semantics are locally defined. The RP can simply *stop doing that silliness* (like a global set of OCSP URLs), because that's definitely in Fringe PKI territory where it's already non-interoperable, since other RPs that don't do that local policy aren't able to obtain revocation information because of that. > > That is, "criticality" means "don't skip this bit just because you > don't > understand it: if you do, you risk getting burned". > > Yes, you kind of have to squint to treat criticality as I described it. > Maybe squint so much you can't even see the text, I admit :) > I mean, I would argue that redefining it to the point of incompatible :) --0000000000005b8b9c05b46e62cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 18, 2020 at 11:13 PM Salz= , Rich <rsalz@akamai.com> wro= te:
I don't = understand the inconsistency argument. Are you saying that there are no end= -entity certs used in TLS that do not mistakenly have missing AIA fields?= =C2=A0 =C2=A0Also see next paragraph.

T= his seems an entirely orthogonal discussion?=C2=A0
=C2=A0

>=C2=A0 =C2=A0 Doesn't the lack of OCSP and CRL location information= in the certificate
=C2=A0 =C2=A0 communicate the same information?

I do not see anything in RFC 5280 sec 4.2.2.1 that says the OCSP AIA is the= *only* place where OCSP responder information should be found. The argumen= t that some are making "if it's not in the OCSP AIA there is no OC= SP responder" does not seem supported by the text. Perhaps I am misrea= ding it, or should look to errata or other RFC's -- please point me to = them.

I'm not sure if you're lu= mping me in that "some", but I've repeatedly acknowledged thi= s scenario as being precisely why what you're proposing doesn't mak= e sense.

There are, in effect, three possible sour= ces for OCSP information:
1. The AIA of the certificate
2. The Directory object associated with the DN of the certificate
3. Local Policy

The absence of 1. is our first s= ign that the CA has decided not to provide OCSP information. 2 is just... n= ot a thing in polite society, although I'm sure ITU-T adherents might s= uggest otherwise.

So really, the source of that is= 3.=C2=A0

You gave one such illustration of 3, whe= n you stated "In addition, an RP migh= t have a global list of OCSP responder configured.". There, an RP has = a local policy that (presumably) is some mapping of DN to OCSP URL, althoug= h strictly speaking, it could just be *one* OCSP URL (ah OCSP, how complex = and fickle you are).

=
Yet in that situation, we have an= RP making a decision, independent of the CA, to unilaterally check OCSP. T= hat is a local policy (mis)configuration, and if a local policy does this, = then I fail to see why local policy would or should respect what the CA say= s.

Now, if we assume this extension existed, then we also have = to assume that the client will update to support this local policy, and apr= iori agree with the CA to make use of this extension to indicate such a sce= nario. That is, both local policy AND software must be changed to support t= his scenario.

Yet, if that's our goal, we can accomplish th= e same thing without any software change on the RP side. Given that, in ord= er for this extension to have any relevance in the presence of misconfigure= d local policy, the RP and the CA must agree out-of-band to use this extens= ion, we have to acknowledge that the RP and the CA have some form of relati= onship. A CA can just as equally divide the "certs for which we provid= e no OCSP information for" and the "certs for which we do" i= nto two separate subordinate hierarchies (that is, two different issuer DNs= ). Then our plucky, but misguided, local RP, they simply have to omit provi= ding a URL for the DN of the CA that doesn't provide revocation informa= tion.

Put differently, this mess only exists because of 2 or 3,= and cannot exist because of 1 (at least, as presently described). Because = both 2 and 3 are matters of local policy, any undesirable effect is self-in= flicted, but equally, any intended or desired semantics are locally defined= . The RP can simply *stop doing that silliness* (like a global set of OCSP = URLs), because that's definitely in Fringe PKI territory where it's= already non-interoperable, since other RPs that don't do that local po= licy aren't able to obtain revocation information because of that.

=C2=A0
>=C2=A0 =C2=A0 That is, "criticality" means "don't sk= ip this bit just because you don't
=C2=A0 =C2=A0 understand it: if you do, you risk getting burned".

Yes, you kind of have to squint to treat criticality as I described it. May= be squint so much you can't even see the text, I admit :)

I mean, I would argue that redefining it to the poin= t of incompatible :)=C2=A0
--0000000000005b8b9c05b46e62cf-- From nobody Wed Nov 18 22:20:03 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32623A0E66 for ; Wed, 18 Nov 2020 22:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 azMpR3ayt8Oo for ; Wed, 18 Nov 2020 22:20:00 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641723A0E5E for ; Wed, 18 Nov 2020 22:20:00 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ690g4024661; Thu, 19 Nov 2020 06:19:56 GMT 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=oIZgOdRway80+aAEH0tRp2XoMbp9zDUPQPsAZrvLy04=; b=Zjw58fAc2LAWM1emd9sL/HTdZMm8C9oBxZ6AkP7dt+FCH4TnFGp9MJEG5OTC7+HPEB2R n1fDDkpDz0uFqpJWsg3lJs9BPjHmi32RhDPYnkBU2iZ+bIJvhRIBUP8ahtD89jlbGX1c bf/8fblbSpKpGkyQ5BoJykPJF6Pxu/GAZK+LqA5UEkoJiuJh3X+gWpIc4eTZ+QQUXm+r +syQ4OLHIW7beeKz7otDRQ5iaEMApwRZQZQVeDFDPDwTcK5YMRH3Oz+26gw+/If+u5sL CIGZoCQUETKHaJetafA/Im2pnVJ6+NiASy8be7Z9403fm/o+ASPuG9diDgwvrh1/vXwA bw== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 34w7pxcrjk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 06:19:56 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ6JIUa007603; Thu, 19 Nov 2020 01:19:55 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 34tbf2gv13-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 01:19:55 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 00:19:54 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Thu, 19 Nov 2020 00:19:54 -0600 From: "Salz, Rich" To: Ryan Sleevi CC: Daniel Kahn Gillmor , Mike Ounsworth , LAMPS , Santosh Chokhani Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgADFv4D//9NNAIAAXMoA///G3oA= Date: Thu, 19 Nov 2020 06:19:53 +0000 Message-ID: <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_33F979393CE9450EBE4617D54BF01417akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_03:2020-11-17, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 mlxlogscore=967 phishscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190046 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_03:2020-11-17, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 bulkscore=0 priorityscore=1501 phishscore=0 spamscore=0 suspectscore=0 impostorscore=0 mlxlogscore=885 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190046 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:20:02 -0000 --_000_33F979393CE9450EBE4617D54BF01417akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZXJlIGFyZSwgaW4gZWZmZWN0LCB0aHJlZSBwb3NzaWJsZSBzb3VyY2VzIGZvciBPQ1NQIGlu Zm9ybWF0aW9uOg0KPjEuIFRoZSBBSUEgb2YgdGhlIGNlcnRpZmljYXRlDQo+Mi4gVGhlIERpcmVj dG9yeSBvYmplY3QgYXNzb2NpYXRlZCB3aXRoIHRoZSBETiBvZiB0aGUgY2VydGlmaWNhdGUNCj4z LiBMb2NhbCBQb2xpY3kNCg0KPlRoZSBhYnNlbmNlIG9mIDEuIGlzIG91ciBmaXJzdCBzaWduIHRo YXQgdGhlIENBIGhhcyBkZWNpZGVkIG5vdCB0byBwcm92aWRlIE9DU1AgaW5mb3JtYXRpb24NCg0K SSB3YXMgbm90IGluY2x1ZGluZyB5b3UgaW4gdGhlIOKAnHNvbWXigJ0gIEkgd2FzIGluY2x1ZGlu ZyB5b3UgaW4gdGhlIHF1ZXN0aW9uIGFib3V0IHdoZXJlIFJGQyA1MjgwIHNheXMg4oCcbm90IGhh dmluZyBBSUEgbWVhbnMgdGhlcmXigJlzIG5vIHJlc3BvbmRlcuKAnSAgU28gcGxlYXNlLCB0ZWxs IG1lIGhvdyB5b3UgZ2V0IHRvICMxPyAgWW91IG9mdGVuIHdyb3RlIOKAnGluIHRoZSBjb250ZXh0 IG9mIFJGQyA1MjgwIHByb2Nlc3NpbmcgcnVsZXPigJ0gIFNvIHBsZWFzZSBwb2ludCBtZSB0byB0 aGUgcnVsZT8NCg0K --_000_33F979393CE9450EBE4617D54BF01417akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8L3NwYW4+PC9iPlRoZXJlIGFy ZSwgaW4gZWZmZWN0LCB0aHJlZSBwb3NzaWJsZSBzb3VyY2VzIGZvciBPQ1NQIGluZm9ybWF0aW9u OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OzEuIFRoZSBBSUEgb2YgdGhlIGNlcnRpZmljYXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Mi4gVGhlIERpcmVjdG9yeSBvYmplY3QgYXNz b2NpYXRlZCB3aXRoIHRoZSBETiBvZiB0aGUgY2VydGlmaWNhdGU8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDszLiBMb2NhbCBQb2xpY3k8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1Ro ZSBhYnNlbmNlIG9mIDEuIGlzIG91ciBmaXJzdCBzaWduIHRoYXQgdGhlIENBIGhhcyBkZWNpZGVk IG5vdCB0byBwcm92aWRlIE9DU1AgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB3YXMgbm90IGluY2x1ZGluZyB5b3UgaW4gdGhlIOKAnHNvbWXigJ0mbmJzcDsgSSB3YXMgaW5j bHVkaW5nIHlvdSBpbiB0aGUgcXVlc3Rpb24gYWJvdXQgd2hlcmUgUkZDIDUyODAgc2F5cyDigJxu b3QgaGF2aW5nIEFJQSBtZWFucyB0aGVyZeKAmXMgbm8gcmVzcG9uZGVy4oCdJm5ic3A7IFNvIHBs ZWFzZSwgdGVsbCBtZSBob3cgeW91IGdldCB0byAjMT8mbmJzcDsgWW91IG9mdGVuIHdyb3RlIOKA nGluIHRoZSBjb250ZXh0IG9mIFJGQyA1MjgwIHByb2Nlc3NpbmcNCiBydWxlc+KAnSZuYnNwOyBT byBwbGVhc2UgcG9pbnQgbWUgdG8gdGhlIHJ1bGU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_33F979393CE9450EBE4617D54BF01417akamaicom_-- From nobody Wed Nov 18 23:33:43 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7133A0BD7 for ; Wed, 18 Nov 2020 23:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S0NWxUKJw9F for ; Wed, 18 Nov 2020 23:33:39 -0800 (PST) Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176]) (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 CC4D43A0CB0 for ; Wed, 18 Nov 2020 23:33:39 -0800 (PST) Received: by mail-pg1-f176.google.com with SMTP id t37so3366921pga.7 for ; Wed, 18 Nov 2020 23:33:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RwFTJNKf7EMefV/3gaWQRaUzZIUc6IflSydkuO2h4jY=; b=UzIfp46gbDcAZXz7Bd2wjoZv8vAGxyKNFTzgOAoJWwA0wfxFfb/EQE86ITH6k5c4ln bErhCa+AfY/RneOmZ80zC0+n3aYJKoG/IUx4jp22AbM4bOgWrXHeVx5/pqb7fZ8AjRQD wgYlTEOSYejNfG0IgWIFQ2bHPllU5IZZbVjqntGfa0H/e48Gv36JnivpVXzbua8qkxCH F3oGwDKZrkf6jDBKCZfMxukNQDwYZWVgfoOPZ64m6YHe7LLptiKJwnkmjrmhHzNYPkq7 DgUmqejMvobGK2poW5H/yFoSTB2lHsSY3NRb/0+oFvpvAJaVLhLb6awifKvo3SYJolN5 ikRA== X-Gm-Message-State: AOAM532XKLXjXRJQlWuz38bmScW5ikWk0DjpnUOk+2EYjVSrRmkQOMh2 Nuej9i9jNRxeFj3MGLK4oTkVS5YFfns= X-Google-Smtp-Source: ABdhPJxCOsLjuqpxNmHcVcXIzsMj4dp+dSb7b8dvW2WOkWoBhlUDLWeGtS8F2Sd2O7RFghtTwIk32A== X-Received: by 2002:a17:90a:6445:: with SMTP id y5mr3338855pjm.64.1605771218967; Wed, 18 Nov 2020 23:33:38 -0800 (PST) Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com. [209.85.210.180]) by smtp.gmail.com with ESMTPSA id n68sm28045847pfn.161.2020.11.18.23.33.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Nov 2020 23:33:38 -0800 (PST) Received: by mail-pf1-f180.google.com with SMTP id i8so3611094pfk.10 for ; Wed, 18 Nov 2020 23:33:38 -0800 (PST) X-Received: by 2002:a17:90a:e2d4:: with SMTP id fr20mr2361586pjb.202.1605771218251; Wed, 18 Nov 2020 23:33:38 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> In-Reply-To: <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> From: Ryan Sleevi Date: Thu, 19 Nov 2020 02:33:27 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Cc: Ryan Sleevi , Daniel Kahn Gillmor , Mike Ounsworth , LAMPS , Santosh Chokhani Content-Type: multipart/alternative; boundary="0000000000000df40c05b470bf98" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 07:33:42 -0000 --0000000000000df40c05b470bf98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 19, 2020 at 1:20 AM Salz, Rich wrote: > *>*There are, in effect, three possible sources for OCSP information: > > >1. The AIA of the certificate > > >2. The Directory object associated with the DN of the certificate > > >3. Local Policy > > > > >The absence of 1. is our first sign that the CA has decided not to > provide OCSP information > > > > I was not including you in the =E2=80=9Csome=E2=80=9D I was including yo= u in the question > about where RFC 5280 says =E2=80=9Cnot having AIA means there=E2=80=99s n= o responder=E2=80=9D So > please, tell me how you get to #1? You often wrote =E2=80=9Cin the conte= xt of RFC > 5280 processing rules=E2=80=9D So please point me to the rule? > I'm not sure how to entirely interpret your question. "If the CA has not said something, how do you know the CA has not said something?" Judging by your reaction, I suspect you may have interpreted my statement to mean "If the CA has not provided an OCSP URL, it has authoritatively stated unambiguously it will not provide OCSP", which was certainly not the meaning I was trying to convey. Rather, it was meant to highlight that if the CA has not declared something in the certificate, then within the processing model of RFC 5280, the CA has not directed the client to do something, nor has it committed to the client that it will make something available. That said, this is supported by the text: https://tools.ietf.org/html/rfc5280#section-4.2.2.1 > The id-ad-ocsp OID is used when revocation information for the > certificate containing this extension is available using the Online > Certificate Status Protocol (OCSP) [RFC2560]. The corollary of that is that when id-ad-ocsp OID is not used, there is no such statement by the issuing CA. Further, look at 6.3.3, with respect to CRLs, for which processing begins with > For each distribution point (DP) in the certificate's CRL > distribution points extension, for each corresponding CRL in the > local CRL cache, while ((reasons_mask is not all-reasons) and > (cert_status is UNREVOKED)) perform the following That is, the stated processed CRLs are those that are matched to the crlDistributionPoints extension (compared to, say, the CRL attribute on the CA entry within the X.500 Directory). This is the "standard" algorithm, which then concludes with: > If the revocation status has not been determined, repeat the process > above with any available CRLs not specified in a distribution point > but issued by the certificate issuer. For the processing of such a > CRL, assume a DP with both the reasons and the cRLIssuer fields > omitted and a distribution point name of the certificate issuer. However, the "any available CRLs" is not part of the standard, it is effectively determined by local policy, which has repeatedly been my point. Although RFC 6960 does not describe an explicit processing model, it is designed to provide equivalent semantics as the CRL within this observable state machine. Further, RFC 6960, Section 2.2, acknowledges that there are three possible responders: 1) The CA that issued the certificate 2) A CA Authorized responder directly issued by the CA 3) Or... a "Trusted Responder" whose public key is trusted by the requester (aka local policy) In the absence of the extension with respect to RFC 5280 4.2.2.1, any use of a responder, whether the CA's responder or a locally-configured Trusted Responder, is entirely determined by local policy. You described one such local policy implementation: a mapping between CA DN to URI. However, I'm not aware of any requirement in the relevant specifications that require a "single" OCSP URL for a CA DN. The requirement is merely that a service listed in the certificate should be able to respond about that certificate. That is, just like a CA can segment CRLs, there's nothing intrinsic that prevents a CA from segmenting OCSP responders (e.g. serials 0-50 go to http://foo.example and serials 51-100 go to http://bar.example), and the algorithms still hold out. So, again I say, any issue resulting from always checking a particular responder, even in the absence of an affirmative declaration by the CA, is an issue driven by local policy, and thus can equally be solved by local policy. --0000000000000df40c05b470bf98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 19, 2020 at 1:20 AM Salz,= Rich <rsalz@akamai.com> wrot= e:

>The= re are, in effect, three possible sources for OCSP information:

>1. The AIA of the certificate

>2. The Directory object associated with the DN o= f the certificate

>3. Local Policy

=C2=A0

>The absence of 1. is our first sign that the CA = has decided not to provide OCSP information

=C2=A0

I was not including you in the =E2=80=9Csome=E2=80= =9D=C2=A0 I was including you in the question about where RFC 5280 says =E2= =80=9Cnot having AIA means there=E2=80=99s no responder=E2=80=9D=C2=A0 So p= lease, tell me how you get to #1?=C2=A0 You often wrote =E2=80=9Cin the con= text of RFC 5280 processing rules=E2=80=9D=C2=A0 So please point me to the rule?

=

I'm not sure how to entire= ly interpret your question. "If the CA has not said something, how do = you know the CA has not said something?"

Judg= ing by your reaction, I suspect you may have interpreted my statement to me= an "If the CA has not provided an OCSP URL, it has authoritatively sta= ted unambiguously it will not provide OCSP", which was certainly not t= he meaning I was trying to convey. Rather, it was meant to highlight that i= f the CA has not declared something in the certificate, then within the pro= cessing model of RFC 5280, the CA has not directed the client to do somethi= ng, nor has it committed to the client that it will make something availabl= e.

That said, this is supported by the text:
=

= >=C2=A0 =C2=A0 The id-ad-ocsp OID is used when revocation information fo= r the
>=C2=A0 =C2=A0certificate containing this extension is availa= ble using the Online
>=C2=A0 =C2=A0Certificate Status Protocol (OCSP)= [RFC2560].

The corollary of that is that when id-ad-ocsp OID is not used, there = is no such statement by the issuing CA.
Further, look at 6.3.3, with respect to C= RLs, for which processing begins with
>= =C2=A0 =C2=A0For each distribution point (DP) in the certificate's CRL<= /div>>=C2=A0 =C2=A0distribution points extension, for each corresponding= CRL in the
>=C2=A0 =C2=A0local CRL cache, while ((reasons_mask is no= t all-reasons) and
>=C2=A0 =C2=A0(cert_status is UNREVOKED)) perform = the following

That is, the stated processed CRLs are tho= se that are matched to the crlDistributionPoints extension (compared to, sa= y, the CRL attribute on the CA entry within the X.500 Directory).

This is the "standard" algorithm, which then conc= ludes with:
>=C2=A0 =C2=A0If the revocation status has not bee= n determined, repeat the process
>=C2=A0 =C2=A0above with any availab= le CRLs not specified in a distribution point
>=C2=A0 =C2=A0but issue= d by the certificate issuer.=C2=A0 For the processing of such a
>=C2= =A0 =C2=A0CRL, assume a DP with both the reasons and the cRLIssuer fields>=C2=A0 =C2=A0omitted and a distribution point name of the certificate= issuer.

However, the "any available CRLs= " is not part of the standard, it is effectively determined by local p= olicy, which has repeatedly been my point.

Althoug= h RFC 6960 does not describe an explicit processing model, it is designed t= o provide equivalent semantics as the CRL within this observable state mach= ine. Further, RFC 6960, Section 2.2, acknowledges that there are three poss= ible responders:
1) The CA that issued the certificate
= 2) A CA Authorized responder directly issued by the CA
3) Or... a= "Trusted Responder" whose public key is trusted by the requester= (aka local policy)

In the absence of the extensio= n with respect to RFC 5280 4.2.2.1, any use of a responder, whether the CA&= #39;s responder or a locally-configured Trusted Responder, is entirely dete= rmined by local policy. You described one such local policy implementation:= a mapping between CA DN to=C2=A0URI.

However, I&#= 39;m not aware of any requirement in the relevant specifications that requi= re a "single" OCSP URL for a CA DN. The requirement is merely tha= t a service listed in the certificate should be able to respond about that = certificate. That is, just like a CA can segment CRLs, there's nothing = intrinsic that prevents a CA from segmenting OCSP responders (e.g. serials = 0-50 go to http://foo.example and serial= s 51-100 go to http://bar.example), and = the algorithms still hold out.

So, again I say, an= y issue resulting from always checking a particular responder, even in the = absence of an affirmative declaration by the CA, is an issue driven by loca= l policy, and thus can equally be solved by local policy.
--0000000000000df40c05b470bf98-- From nobody Thu Nov 19 00:52:45 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F823A1201 for ; Thu, 19 Nov 2020 00:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=UCCtll8X; dkim=pass (1024-bit key) header.d=primekey.com header.b=VrdeEcOz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I08klSBZzYsf for ; Thu, 19 Nov 2020 00:52:41 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACA93A1203 for ; Thu, 19 Nov 2020 00:52:40 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id F2AED6AA4FB0 for ; Thu, 19 Nov 2020 09:52:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1605775957; bh=8xCaor8JNzeL+7UVp1gtNEBhcvGvWUDs0yxguQuzXEo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UCCtll8XYrYwZT4J6f4EbW555uZTf5xWv6FUzta3HIxuwuNII5a41mCuYWRGUjhf7 2nHFO19QlpoUwKXuMqKwcIGIUcOgykvRJRm6ABizdyWEj5cdQRt1nuJUlX0BGhCjNt uQCnYNOqHEkjoYD5QP8YZqJjssk1pBCkM2SwYjxU= Received: from [10.11.0.7] (unknown [10.11.0.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id D329B6AA4FAE for ; Thu, 19 Nov 2020 09:52:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1605775956; bh=8xCaor8JNzeL+7UVp1gtNEBhcvGvWUDs0yxguQuzXEo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=VrdeEcOzlHeRATSlwXRvBss3ux6CzQ8tE53GT+tAyhNVJdshVR2muoBUs7En/WO98 dx6Q5U5XW7flS+wcocDBe7lFUGOGkhoIJdl2MabCsxjCaqfCDTXmHJCkEryzGS8G3W V1tKuY99DPMrzk/O4IuiTHjC4jE5QxS4iEUeI06k= To: spasm@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Thu, 19 Nov 2020 09:52:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 08:52:44 -0000 I agree with the nay sayers. I don't see enough benefits that outweigh the complications introduced by adding such an extension. I am not aware of any real use cases or client implemntations where revocation checking is an issue today, that would be helped by such an extension. Best regards, Tomas On 2020-11-19 08:33, Ryan Sleevi wrote: > > > On Thu, Nov 19, 2020 at 1:20 AM Salz, Rich > wrote: > > *>*There are, in effect, three possible sources for OCSP > information:____ > > >1. The AIA of the certificate____ > > >2. The Directory object associated with the DN of the certificate____ > > >3. Local Policy____ > > __ __ > > >The absence of 1. is our first sign that the CA has decided not to > provide OCSP information____ > > __ __ > > I was not including you in the “some”  I was including you in the > question about where RFC 5280 says “not having AIA means there’s no > responder”  So please, tell me how you get to #1?  You often wrote > “in the context of RFC 5280 processing rules”  So please point me to > the rule? > > > I'm not sure how to entirely interpret your question. "If the CA has not > said something, how do you know the CA has not said something?" > > Judging by your reaction, I suspect you may have interpreted my > statement to mean "If the CA has not provided an OCSP URL, it has > authoritatively stated unambiguously it will not provide OCSP", which > was certainly not the meaning I was trying to convey. Rather, it was > meant to highlight that if the CA has not declared something in the > certificate, then within the processing model of RFC 5280, the CA has > not directed the client to do something, nor has it committed to the > client that it will make something available. > > That said, this is supported by the text: > > https://tools.ietf.org/html/rfc5280#section-4.2.2.1 >>    The id-ad-ocsp OID is used when revocation information for the >>   certificate containing this extension is available using the Online >>   Certificate Status Protocol (OCSP) [RFC2560]. > > The corollary of that is that when id-ad-ocsp OID is not used, there is > no such statement by the issuing CA. > > Further, look at 6.3.3, with respect to CRLs, for which processing > begins with >>   For each distribution point (DP) in the certificate's CRL >>   distribution points extension, for each corresponding CRL in the >>   local CRL cache, while ((reasons_mask is not all-reasons) and >>   (cert_status is UNREVOKED)) perform the following > > That is, the stated processed CRLs are those that are matched to the > crlDistributionPoints extension (compared to, say, the CRL attribute on > the CA entry within the X.500 Directory). > > This is the "standard" algorithm, which then concludes with: >>   If the revocation status has not been determined, repeat the process >>   above with any available CRLs not specified in a distribution point >>   but issued by the certificate issuer.  For the processing of such a >>   CRL, assume a DP with both the reasons and the cRLIssuer fields >>   omitted and a distribution point name of the certificate issuer. > > However, the "any available CRLs" is not part of the standard, it is > effectively determined by local policy, which has repeatedly been my point. > > Although RFC 6960 does not describe an explicit processing model, it is > designed to provide equivalent semantics as the CRL within this > observable state machine. Further, RFC 6960, Section 2.2, acknowledges > that there are three possible responders: > 1) The CA that issued the certificate > 2) A CA Authorized responder directly issued by the CA > 3) Or... a "Trusted Responder" whose public key is trusted by the > requester (aka local policy) > > In the absence of the extension with respect to RFC 5280 4.2.2.1, any > use of a responder, whether the CA's responder or a locally-configured > Trusted Responder, is entirely determined by local policy. You described > one such local policy implementation: a mapping between CA DN to URI. > > However, I'm not aware of any requirement in the relevant specifications > that require a "single" OCSP URL for a CA DN. The requirement is merely > that a service listed in the certificate should be able to respond about > that certificate. That is, just like a CA can segment CRLs, there's > nothing intrinsic that prevents a CA from segmenting OCSP responders > (e.g. serials 0-50 go to http://foo.example and serials 51-100 go to > http://bar.example), and the algorithms still hold out. > > So, again I say, any issue resulting from always checking a particular > responder, even in the absence of an affirmative declaration by the CA, > is an issue driven by local policy, and thus can equally be solved by > local policy. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Nov 19 01:28:22 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96B83A138B for ; Thu, 19 Nov 2020 01:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 uARTgVGQzSw9 for ; Thu, 19 Nov 2020 01:28:13 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 7F28B3A12DF for ; Thu, 19 Nov 2020 01:28:02 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id d17so5307658ion.4 for ; Thu, 19 Nov 2020 01:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=vAu4XzF1Ug65hVQsJcWA/UxEOxKTmCbLmPirufO0YC0=; b=db/yTWpHgLJX2UNflmqhWcbLKY8+xWqOnni08CHQKFZFMZ9plZD8HF+zJ1NJ3nC69Y 20s7c/kckjw5TB+6ufFt5nlkbwJZcKdF3PTFEN5T74nsdfXMGEUT1x7lMTOldQekFa9b gWfBlc0MR8L5J5Um+a9CL4bx9DosXY4VeWNd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=vAu4XzF1Ug65hVQsJcWA/UxEOxKTmCbLmPirufO0YC0=; b=ujojBMWVPyt/noDaTKRZyvQ/IMab/8WaIuN5/djGdoM/vg6StBoy7sNIWOoWjU1Zam VvJR0C5uj5zfxo2Fo4HVz5NlRdz3SyOAYLPaqrPbcN8/p3luxb4n/dWI7Y5d2+B1ZOXE nVI3qLVwpjxZWOEFXmZzhU6/Nvn5KzxHP0BMKryQMlUQ99wLmoB7wCpLLCmzfdPtiJBE G4QMPIhKYk/g6Rj753KzXtV7kDVDoi/pdLpC/JpfkrMi1YcG+Lu0PvGxP4yr1w51CS2g zhhDRzHsg5s5rwRzjPvIBILowdYN+XThhRM+TvfZAUL+oCL54/gyGH4gUOSfgGxZUT7a Q9vw== X-Gm-Message-State: AOAM530NE9VeeycVctROpko9Z7Ex598hPHYAA9G6hVmecJ4ZLq/FxasJ EGsrlvnWbKW3E+cECtPCZiAR8w== X-Google-Smtp-Source: ABdhPJy/xghoEYlepOGVRuP/dcOMuF3gTPc1erICRN4fMOx4M7Qk82TeyE81d3AQHsiNJd+LLY+7ug== X-Received: by 2002:a6b:6016:: with SMTP id r22mr18982443iog.93.1605778081461; Thu, 19 Nov 2020 01:28:01 -0800 (PST) Received: from [192.168.2.143] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id u16sm333867ilj.6.2020.11.19.01.27.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 01:28:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Thu, 19 Nov 2020 04:27:59 -0500 From: Carl Wallace To: "Salz, Rich" , Ryan Sleevi CC: LAMPS , Santosh Chokhani , Mike Ounsworth , Daniel Kahn Gillmor Message-ID: Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> In-Reply-To: <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688604880_1993484521" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:28:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688604880_1993484521 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: Spasm on behalf of "Salz, Rich" =20 I was not including you in the =E2=80=9Csome=E2=80=9D I was including you in the quest= ion about where RFC 5280 says =E2=80=9Cnot having AIA means there=E2=80=99s no responder= =E2=80=9D So please, tell me how you get to #1? You often wrote =E2=80=9Cin the contex= t of RFC 5280 processing rules=E2=80=9D So please point me to the rule? =20 [CW] Also not sure who =E2=80=98some=E2=80=99 refers to, but my point was not that not = having an AIA means there is no responder but that having an extension to ex= plicitly tell me you don=E2=80=99t publish anything doesn=E2=80=99t mean anything at all= to me if I elect to consider a cert revoked and that the provided definitio= n leaves open to interpretation the meaning of the many certs in existence t= hat lack AIA, CRL DP and the TBD extension. I still think that *if* there is= to be a =E2=80=98positive statement=E2=80=99 it should be of the form =E2=80=9Cyes there is r= evocation info, but I am not telling you where it is in this cert=E2=80=9D. It may= be possible to fashion a statement of this sort as an AIA and spare creatin= g a new extension to parse. Re-using AIA would take care of criticality sema= ntics as well. Certs without new indicator, OCSP AIA or CRL DP would mean wh= at they mean today =E2=80=93 the CA has elected to not include a reference to revo= cation info source in the cert.=20 --B_3688604880_1993484521 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

From: Spasm <sp= asm-bounces@ietf.org> on behalf of "Salz, Rich" <rsalz=3D40aka= mai.com@dmarc.ietf.org>
<snip> 

I was not inc= luding you in the =E2=80=9Csome=E2=80=9D  I was including you in the question about= where RFC 5280 says =E2=80=9Cnot having AIA means there=E2=80=99s no responder=E2=80=9D = So please, tell me how you get to #1?  You often wrote =E2=80=9Cin the conte= xt of RFC 5280 processing rules=E2=80=9D  So please point me to the rule?

 

[CW] Also not sure who =E2=80=98some=E2=80=99 refers to, but my point was not that = not having an AIA means there is no responder but that having an extension t= o explicitly tell me you don=E2=80=99t publish anything doesn=E2=80=99t mean anything at= all to me if I elect to consider a cert revoked and that the provided defin= ition leaves open to interpretation the meaning of the many certs in existen= ce that lack AIA, CRL DP and the TBD extension. I still think that *if* there is to be a =E2=80=98positive statement=E2=80=99 it should be of the form =E2=80=9Cyes= there is revocation info, but I am not telling you where it is in this cert= =E2=80=9D. It may be possible to fashion a statement of this sort as an AIA and sp= are creating a new extension to parse. Re-using AIA would take care of criti= cality semantics as well. Certs without new indicator, OCSP AIA or CRL DP wo= uld mean what they mean today =E2=80=93 the CA has elected to not include a refere= nce to revocation info source in the cert.

--B_3688604880_1993484521-- From nobody Thu Nov 19 01:49:25 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D1C3A12F7 for ; Thu, 19 Nov 2020 01:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 H4Hs---0dgki for ; Thu, 19 Nov 2020 01:49:21 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4DA3A1269 for ; Thu, 19 Nov 2020 01:49:21 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ9gtYm009942; Thu, 19 Nov 2020 09:49:20 GMT 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=IQOoSfPvFtS1R3Ydnp/sUWNuy09gEFARyjVMk1WhtkU=; b=mzYKSDdRymkLWaUNRUv1s+m00tz1e4xQBLjmOm3GJaJ7sK3/fn5rqGgO2XZUC18rPNWM qEXWEVPPqGozivJffpmp0HpHmm0J3D+mw6THnzBh9h9Us8b0qvIU4uWLCgx4BPvFj3Fr VxrnucRNjdcC65Vtv2aJkobiso9N0iip0fHSaNQJqkkABmoY+LOgHopddocDkDMMGNP0 +P77NesxzPrvEceg5vxrigx1vD4kfHCtGyRI0dMUpkLp6JnfEBgNk/2M7ecSROaK7OLs FegpJTHqK9Ar4N8aLiRbL+Nk1hnXbfAwKksvRT4lsJUz6zG5b5eyRQCFiB7kYoydJs05 Lg== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 34w7r7ukdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 09:49:20 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJ9YF8a028410; Thu, 19 Nov 2020 04:49:19 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint4.akamai.com with ESMTP id 34tbf3a0ju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 04:49:19 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 03:49:18 -0600 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.007; Thu, 19 Nov 2020 03:49:18 -0600 From: "Salz, Rich" To: Carl Wallace CC: LAMPS Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgADFv4D//9NNAIAAXMoA///G3oCAAIhggP//siKA Date: Thu, 19 Nov 2020 09:49:17 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_B6CF2D825E8F49C7B25788E5B7F33CFFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_05:2020-11-17, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=884 bulkscore=0 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_05:2020-11-17, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=796 impostorscore=0 priorityscore=1501 bulkscore=0 phishscore=0 spamscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190070 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 09:49:24 -0000 --_000_B6CF2D825E8F49C7B25788E5B7F33CFFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgW0NXXSBBbHNvIG5vdCBzdXJlIHdobyDigJhzb21l4oCZIHJlZmVycyB0bywgYnV0IG15 IHBvaW50IHdhcyBub3QgdGhhdCBub3QgaGF2aW5nIGFuIEFJQSBtZWFucyB0aGVyZSBpcyBubyBy ZXNwb25kZXIgYnV0IHRoYXQgaGF2aW5nIGFuIGV4dGVuc2lvbiB0byBleHBsaWNpdGx5IHRlbGwg bWUgeW91IGRvbuKAmXQgcHVibGlzaCBhbnl0aGluZyBkb2VzbuKAmXQgbWVhbiBhbnl0aGluZyBh dCBhbGwgdG8gbWUgaWYgSSBlbGVjdCB0byBjb25zaWRlciBhIGNlcnQgcmV2b2tlZCBhbmQgdGhh dCB0aGUgcHJvdmlkZWQgZGVmaW5pdGlvbiBsZWF2ZXMgb3BlbiB0byBpbnRlcnByZXRhdGlvbiB0 aGUgbWVhbmluZyBvZiB0aGUgbWFueSBjZXJ0cyBpbiBleGlzdGVuY2UgdGhhdCBsYWNrIEFJQSwg Q1JMIERQIGFuZCB0aGUgVEJEIGV4dGVuc2lvbi4NCg0KSWYgYSBjZXJ0IERPRVMgaGF2ZSBhbiBP Q1NQIEFJQSwgYXJlIHlvdSBzdGlsbCBmcmVlIHRvIGNvbnNpZGVyIGl0IHJldm9rZWQgaW4geW91 ciBwcm9jZXNzaW5nPyAgSWYgc28sIHdoeSBpcyB0aGUgbm9SZXZBdmFpbCBkaWZmZXJlbnQ/DQo= --_000_B6CF2D825E8F49C7B25788E5B7F33CFFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <622CD09D5E22EF4094029B60BB09417D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE3MTQzMDU5ODM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0yMDIwNjg3MjgwIC0xMTIyNzk5NjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+W0NXXSBBbHNv IG5vdCBzdXJlIHdobyDigJhzb21l4oCZIHJlZmVycyB0bywgYnV0IG15IHBvaW50IHdhcyBub3Qg dGhhdCBub3QgaGF2aW5nIGFuIEFJQSBtZWFucyB0aGVyZSBpcyBubyByZXNwb25kZXIgYnV0IHRo YXQgaGF2aW5nIGFuIGV4dGVuc2lvbiB0byBleHBsaWNpdGx5IHRlbGwgbWUgeW91IGRvbuKAmXQg cHVibGlzaA0KIGFueXRoaW5nIGRvZXNu4oCZdCBtZWFuIGFueXRoaW5nIGF0IGFsbCB0byBtZSBp ZiBJIGVsZWN0IHRvIGNvbnNpZGVyIGEgY2VydCByZXZva2VkIGFuZCB0aGF0IHRoZSBwcm92aWRl ZCBkZWZpbml0aW9uIGxlYXZlcyBvcGVuIHRvIGludGVycHJldGF0aW9uIHRoZSBtZWFuaW5nIG9m IHRoZSBtYW55IGNlcnRzIGluIGV4aXN0ZW5jZSB0aGF0IGxhY2sgQUlBLCBDUkwgRFAgYW5kIHRo ZSBUQkQgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhIGNlcnQg RE9FUyBoYXZlIGFuIE9DU1AgQUlBLCBhcmUgeW91IHN0aWxsIGZyZWUgdG8gY29uc2lkZXIgaXQg cmV2b2tlZCBpbiB5b3VyIHByb2Nlc3Npbmc/Jm5ic3A7IElmIHNvLCB3aHkgaXMgdGhlIG5vUmV2 QXZhaWwgZGlmZmVyZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B6CF2D825E8F49C7B25788E5B7F33CFFakamaicom_-- From nobody Thu Nov 19 03:00:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474B43A045E for ; Thu, 19 Nov 2020 03:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=er7VZa2N; dkim=pass (1024-bit key) header.d=primekey.com header.b=er7VZa2N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWLSK44Ie0Bz for ; Thu, 19 Nov 2020 03:00:46 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A793A046A for ; Thu, 19 Nov 2020 03:00:45 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 835EE6AA618F for ; Thu, 19 Nov 2020 12:00:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1605783642; bh=nixJhMDcHtzGV4z+cbAn7/4C2RGmP3tKYF9B47DcACs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=er7VZa2NCLobgx7B3nUtnV2Z+7E9rABek1940bZCpYmGP/M/JddmaMan6Tq+ADHkZ EUh+gijJkNsg3x5mtYIk3sGocCQ/S4FD1btIKN2NLT57CcV8tB91Y13vrtdgKEuJND tkQjgP52ZTxuC6ntBydj0Mzj20uKQ3oKQ8QALqE0= Received: from [10.11.0.7] (unknown [10.11.0.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 64AD86AA618E for ; Thu, 19 Nov 2020 12:00:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1605783642; bh=nixJhMDcHtzGV4z+cbAn7/4C2RGmP3tKYF9B47DcACs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=er7VZa2NCLobgx7B3nUtnV2Z+7E9rABek1940bZCpYmGP/M/JddmaMan6Tq+ADHkZ EUh+gijJkNsg3x5mtYIk3sGocCQ/S4FD1btIKN2NLT57CcV8tB91Y13vrtdgKEuJND tkQjgP52ZTxuC6ntBydj0Mzj20uKQ3oKQ8QALqE0= To: spasm@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <02e0ae5a-440c-02e2-5c2d-7404ac3232ea@primekey.com> Date: Thu, 19 Nov 2020 12:00:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 11:00:48 -0000 On 2020-11-19 10:49, Salz, Rich wrote: > * [CW] Also not sure who ‘some’ refers to, but my point was not that > not having an AIA means there is no responder but that having an > extension to explicitly tell me you don’t publish anything doesn’t > mean anything at all to me if I elect to consider a cert revoked and > that the provided definition leaves open to interpretation the > meaning of the many certs in existence that lack AIA, CRL DP and the > TBD extension. > >   > > If a cert DOES have an OCSP AIA, are you still free to consider it > revoked in your processing?  If so, why is the noRevAvail different? For sure you are very free. Hard-fail, soft-fail, interpretation of OCSP UNKNOWN. Many discussions there have been on these variants. OCSP AIA gives some valuable information for the processing logic. I don't see how noRevAvail provides much valuable information. I can imagine: - don't check the local CRL cache that may save a few CPU cycles, but that gain is small as there will be no CRL, or CRL entries, in the CRL cache for this certificate On the theoretical side: Such an extension can give opportunity to some very bad practices. Such as mixing issuance, from the same CA, of certificates which the CA keep track of, with issuance of certificates that the CA does not keep track of (we call such certificate throw away certificates). Issued under different policies, I think best practice is to issue them from separate Issuing CAs, in which case noRevAvail does not add any new information. Encouraging mixing use cases where revocation is important with use cases where revocation is not used seems like a potentially dangerous practice. Cheers, Tomas From nobody Thu Nov 19 03:26:25 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EDA3A0AB7 for ; Thu, 19 Nov 2020 03:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 o85H77NyKH3L for ; Thu, 19 Nov 2020 03:26:20 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 0EE9C3A09CF for ; Thu, 19 Nov 2020 03:26:19 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id r9so5641958ioo.7 for ; Thu, 19 Nov 2020 03:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=lmcUZp3ByRhu3sEDkBCMMMTfpKpn4axG13sWLHNbdHs=; b=tYemn5Pe9KBHxjfi1YtXhj0nrFfa5lJW2pCJXUX0WkE5TyIKZ67Zh+NLw57QLuZ0zk HRu/v9YIJNFsxVlyOGA9OAsD0yEePJW+Yk5zhN+cIDMkm/ioak77nnrLnmu9PacW1Ip5 PKsRWO4HxKBRTYbBpq/205Dph6DfWiLMN7eXU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=lmcUZp3ByRhu3sEDkBCMMMTfpKpn4axG13sWLHNbdHs=; b=HDo5hcJBHLpufHLpsVuIk7uWxkXhVhgQmLW6gF9rHNc+jVTBZXcMMfMBvuEomf8FxE hVXJuRvBRyYi8pGMyUHzK9Q1865Mm/9rK3ORRT9LUg8sjkQTPIdZdV82d2aZUq6u5PJt LuPeHPy/jVnV2+gh3tuqoC689iN3lI7u1i8CYFasCSbxX5XZB++JGt4ngvbSvUmAV2vR iq+/ucqBM7VXeivLXoExOqwSaQr2INvDgZkpShZViGvox1uSi6vFIUOGKwrb71IJM6dG PCLmnX6fXAELGh0duFj3TZfxonOT1LzRiPagcwGPHZ5zbdns0eQkOCqMBMLbJ6ZVU0/T 7pNQ== X-Gm-Message-State: AOAM532gMYssOm4Cl4SbAEqgZiHGbnAZx6tCUyMJ6HUAEZ+jKxAoLa6v 8GdrKtauFhc/3BI5uwHwsRqYuw== X-Google-Smtp-Source: ABdhPJyjRmO8ojeNUBuNo3IM2I0HoRDi7F+xYSLFpgSrP0fMtUfUP7XKJOPJZet7qbp8GIK+gZFJww== X-Received: by 2002:a5d:9cc7:: with SMTP id w7mr20009520iow.202.1605785179005; Thu, 19 Nov 2020 03:26:19 -0800 (PST) Received: from [192.168.2.16] (pool-108-18-106-102.washdc.fios.verizon.net. [108.18.106.102]) by smtp.gmail.com with ESMTPSA id j5sm14294598ioa.28.2020.11.19.03.26.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 03:26:18 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.1b.201012 Date: Thu, 19 Nov 2020 06:26:17 -0500 From: Carl Wallace To: "Salz, Rich" CC: LAMPS Message-ID: <615BE432-A9AE-4413-B9C5-C88DC1F15A08@redhoundsoftware.com> Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3688611978_1172439081" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 11:26:23 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3688611978_1172439081 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 From: "Salz, Rich" Date: Thursday, November 19, 2020 at 4:49 AM To: Carl Wallace Cc: LAMPS Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension =20 [CW] Also not sure who =E2=80=98some=E2=80=99 refers to, but my point was not that not = having an AIA means there is no responder but that having an extension to ex= plicitly tell me you don=E2=80=99t publish anything doesn=E2=80=99t mean anything at all= to me if I elect to consider a cert revoked and that the provided definitio= n leaves open to interpretation the meaning of the many certs in existence t= hat lack AIA, CRL DP and the TBD extension. =20 If a cert DOES have an OCSP AIA, are you still free to consider it revoked = in your processing? If so, why is the noRevAvail different? =20 [CW] You wrote the words =E2=80=9CMUST NOT use such information=E2=80=9D so you would n= eed to answer that one. Given you have elsewhere backed off that definition,= i.e., =E2=80=9CMaybe squint so much you can't even see the text, I admit=E2=80=9D was a= fter your =E2=80=9CI prefer the language I first proposed=E2=80=9C with regards to criti= cality, I will wait for a new definition for the new extension semantics bef= ore commenting further other than to reiterate that I see no need for this e= xtension but would prefer a statement that revocation info is available but = no reference is provided if something must be defined towards this end. --B_3688611978_1172439081 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

From: "Salz, Rich" <rsalz@akamai.co= m>
Date: Thursday, November 19, 2020 at 4:49 AM
To: C= arl Wallace <carl@redhoundsoftware.com>
Cc: LAMPS <spasm@= ietf.org>
Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAva= il extension

 <= /o:p>

  • [CW] Also not sure who =E2=80= =98some=E2=80=99 refers to, but my point was not that not having an AIA means there = is no responder but that having an extension to explicitly tell me you don=E2=80= =99t publish anything doesn=E2=80=99t mean anything at all to me if I elect to consi= der a cert revoked and that the provided definition leaves open to interpret= ation the meaning of the many certs in existence that lack AIA, CRL DP and t= he TBD extension.

 

If a cert DOES have an OCSP AIA, are you still free to = consider it revoked in your processing?  If so, why is the noRevAvail d= ifferent?

 

[CW] You wrote the words =E2=80=9CMUST NOT use such information=E2=80=9D so you w= ould need to answer that one. Given you have elsewhere backed off that defin= ition, i.e., =E2=80=9CMaybe squint so much you can't even see the text, I admit=E2=80=9D= was after your =E2=80=9CI prefer the language I first p= roposed=E2=80=9C with regards to criticality, I will wait for a new definit= ion for the new extension semantics before commenting further other than to = reiterate that I see no need for this extension but would prefer a statement= that revocation info is available but no reference is provided if something= must be defined towards this end.

--B_3688611978_1172439081-- From nobody Thu Nov 19 07:26:25 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3C03A0B0B for ; Thu, 19 Nov 2020 07:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 buull_XBPpap for ; Thu, 19 Nov 2020 07:26:21 -0800 (PST) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 586293A0B08 for ; Thu, 19 Nov 2020 07:26:21 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id o3so5609453ota.8 for ; Thu, 19 Nov 2020 07:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z6Uux7xZ2wT9wvdX/8zIgcCc/BuqvqPgT0p8SySEePE=; b=Yc795RBP3G0VAb6tY/BM4umYR4hEsxe+mG2E9OXn8bUcZIi9kQd5R27I0A2F/jo/JU xJScDRQp8YIaaY/+dUMX3J6is93pRzyzDFIjDVeQ06fQRMzaMDOgOm7zy1BipoGKtVr6 dZ07pNp8pORHZumsQk5M/e9Akyl3GDqhdFFbS2bSVODMl/ivbyEiEYXFUPxEWavrffaj qJlyZyaSlnspLTHi7tMUc3s0MXEY7iEPRdM2vRu/K+qqc06NCEL7/1NQo3h/GuvFbGvl szdTb9dS3kVVv1lDWhSaPinBSXa4rpyX1pzyi+zuB+LX+JpG/PK+wXDMR4BJlLAoMFtb 9edQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z6Uux7xZ2wT9wvdX/8zIgcCc/BuqvqPgT0p8SySEePE=; b=VJVsuUceC7HfxRm92O4t5f2jOuPPiU8yfaNCnJrHJxwX7IcXagJl4Iw7YPQ0nennU4 XBNO2BBHJHU9R0pfDGpjWV1Xh8H3FWVbhBSDn1diIDf1k6OfZVvNvUuq8rMo7zYhz238 qPK7uVcai3X73wdaW5NEJx2PoizxCAx5Sztwp0QOoWUx3L6UwiIAPleS6rIqTsl/1CGT kxUiOCGlzgSKeiMRTfuFtF9I5f5/H5cRYTXaPZ5wLsHh5a0jjGUoqw8jfRk7nTwSAweM aA8JbXua9gVa3XOEo0e/nu6FPwXKCaP/0iG1uRHOgPm/HpRsDdpJqxvFqgAH/iCXVPHf EXUQ== X-Gm-Message-State: AOAM531PMKGdcsnI+5IthMjG8uzeMBUvDkj1muJQqEB9wzCXaKOPzqhq Rq+DIwNLXxAISfV/+aZLZ65k6z57hXvZKZfFNNTRujI= X-Google-Smtp-Source: ABdhPJwJ9I+LrM3HuMvJc24aPDzZqTdgDMlaR5saE3AOsRjqP+QQPtBBTz3anCao9ARSX7K6v7iPZEv+1NA4J6rNwQo= X-Received: by 2002:a05:6830:11:: with SMTP id c17mr10774304otp.304.1605799580111; Thu, 19 Nov 2020 07:26:20 -0800 (PST) MIME-Version: 1.0 References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> <615BE432-A9AE-4413-B9C5-C88DC1F15A08@redhoundsoftware.com> In-Reply-To: <615BE432-A9AE-4413-B9C5-C88DC1F15A08@redhoundsoftware.com> From: Deb Cooley Date: Thu, 19 Nov 2020 10:26:08 -0500 Message-ID: To: LAMPS Cc: "Cooley, Dorothy E" Content-Type: multipart/alternative; boundary="0000000000008d997b05b47759e4" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:26:24 -0000 --0000000000008d997b05b47759e4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wow.... Here is my vote (w/ some notes below). 1. don't add a new extension (and definitely don't overload the ocsp-nocheck extension). 2. if one doesn't want to publish revocation information, then one should merely not publish CRL DP and OSCP AIA (for whatever the correct language is there) 3. The systems that 'require' revocation checking are few and far between. I'm frankly surprised that DKG managed to find one. I know what I would recommend to them, if they were to ask me for advice, which they won't. LOL. 4. Making an extension critical is merely a recipe for disaster. And guess what? The RPs don't pay one bit of attention. I have examples of a vendor happily using a key agreement cert for signature (KU is classically marked as critical). I can't even. Notes: A. My employer has systems where we don't publish either CRL DP and OCSP AIA, not because we don't produce revocation information, but because of the latency it would add having a RP reach back through multiple networks and boundaries to do that checking. Instead we push those responses and CRLs to locations that are easily reachable by the RP. This allows us to enable revocation checking w/out incurring a large latency issue. Note: the use cases here span authentication, document signing, email protection, etc. B. I was slightly appalled at the idea that a stapled OCSP response would be ignored if the server certificate didn't populate the OCSP AIA. Maybe I was more than slightly appalled. Dunno. Seems a bit silly. C. RFC5280 is a tiny bit long in the tooth. The grand plans for how PKI could be used have not come to pass (tell me one implementation that parses and/or pays attention to certificate policies, I'll wait, making popcorn). (1) The reality is that what most RPs see (people, sitting in their living rooms, perhaps grandmas) don't want to have to know any of this, they just want it to work. (2) In the enterprise cases (mostly what I work on in my day job), if we can do it under the covers, the RPs don't whine too much (that's a lie, they whine, but we make them use it anyway unless they have lots of stars and then we do it for them). (3) In the cases where there aren't people for RPs, we still have human developers. And it is largely still done incorrectly. D. There is definitely a difference between Web PKI and anything else - S/MIME, code signing, IPSec etc. We should leave the Web PKI issues to the CA/B Forum. This is my longest post, probably ever. Deb Cooley On Thu, Nov 19, 2020 at 6:26 AM Carl Wallace wrote: > > > *From: *"Salz, Rich" > *Date: *Thursday, November 19, 2020 at 4:49 AM > *To: *Carl Wallace > *Cc: *LAMPS > *Subject: *Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension > > > > - [CW] Also not sure who =E2=80=98some=E2=80=99 refers to, but my poin= t was not that > not having an AIA means there is no responder but that having an exten= sion > to explicitly tell me you don=E2=80=99t publish anything doesn=E2=80= =99t mean anything at > all to me if I elect to consider a cert revoked and that the provided > definition leaves open to interpretation the meaning of the many certs= in > existence that lack AIA, CRL DP and the TBD extension. > > > > If a cert DOES have an OCSP AIA, are you still free to consider it revoke= d > in your processing? If so, why is the noRevAvail different? > > > > [CW] You wrote the words =E2=80=9CMUST NOT use such information=E2=80=9D = so you would need > to answer that one. Given you have elsewhere backed off that definition, > i.e., =E2=80=9CMaybe squint so much you can't even see the text, I admit= =E2=80=9D was after > your =E2=80=9CI prefer the language I first proposed=E2=80=9C with regard= s to > criticality, I will wait for a new definition for the new extension > semantics before commenting further other than to reiterate that I see no > need for this extension but would prefer a statement that revocation info > is available but no reference is provided if something must be defined > towards this end. > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --0000000000008d997b05b47759e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wow.... Here is my vote (w/ some notes below).
<= div>
1.=C2=A0 don't add a new extension (and definitely d= on't overload the ocsp-nocheck extension).
2.=C2=A0 if one do= esn't want to publish revocation information, then one should merely no= t publish CRL DP and OSCP AIA (for whatever the correct language is there)<= /div>
3.=C2=A0 The systems that 'require' revocation checking a= re few and far between.=C2=A0 I'm frankly surprised that DKG managed to= find one. I know what I would recommend to them, if they were to ask me fo= r advice, which they won't.=C2=A0 LOL.
4.=C2=A0 Making an ext= ension critical is merely a recipe for disaster.=C2=A0 And guess what?=C2= =A0 The RPs don't pay one bit of attention.=C2=A0 I have examples of a = vendor happily using a key agreement cert for signature (KU is classically = marked as critical).=C2=A0 I can't even.

N= otes:
A.=C2=A0 My employer has systems where we don't pu= blish either CRL DP and OCSP AIA, not because we don't produce revocati= on information, but because of the latency it would add having a RP reach b= ack through multiple networks and boundaries to do that checking.=C2=A0 Ins= tead we push those responses and CRLs to locations that are easily reachabl= e by the RP.=C2=A0 This allows us to enable revocation checking w/out incur= ring a large latency issue.=C2=A0 Note:=C2=A0 the use cases here span authe= ntication, document signing, email protection, etc.

B.=C2=A0 I was slightly appalled at the idea that a stapled OCSP resp= onse would be ignored if the server certificate didn't populate the OCS= P AIA.=C2=A0 Maybe I was more than slightly appalled.=C2=A0 Dunno.=C2=A0 Se= ems a bit silly.

C.=C2=A0 RFC5280 is a tiny bit lo= ng in the tooth.=C2=A0 The grand plans for how PKI could be used have not c= ome to pass (tell me one implementation that parses and/or pays attention t= o certificate policies, I'll wait, making popcorn).=C2=A0
(1) The reality is that what most RPs see (people, sitting in their livin= g rooms, perhaps grandmas) don't want to have to know any of this, they= just want it to work.=C2=A0
(2) In the enterprise cases (mo= stly what I work on in my day job), if we can do it under the covers, the R= Ps don't whine too much (that's a lie, they whine, but we make them= use it anyway unless they have lots of stars and then we do it for them).= =C2=A0
(3) In the cases where there aren't people for RP= s, we still have human developers.=C2=A0 And it is largely still done incor= rectly.

D.=C2=A0 There is definitely a differe= nce between Web PKI and anything else - S/MIME, code signing, IPSec etc.=C2= =A0 We should leave the Web PKI issues to the CA/B Forum.=C2=A0
<= div>
This is my longest post, probably ever.
D= eb Cooley




<= div class=3D"gmail_quote">
On Thu, Nov= 19, 2020 at 6:26 AM Carl Wallace <carl@redhoundsoftware.com> wrote:

=C2=A0

= From: "Salz, Ric= h" <rsalz@aka= mai.com>
Date: Thursday, November 19, 2020 at 4:49 AM
<= b>To: Carl Wallace <carl@redhoundsoftware.com>
Cc: LAMPS <spasm@ietf.org>Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension

=C2=A0

  • [CW] Also n= ot sure who =E2=80=98some=E2=80=99 refers to, but my point was not that not= having an AIA means there is no responder but that having an extension to = explicitly tell me you don=E2=80=99t publish anything doesn=E2=80=99t mean = anything at all to me if I elect to consider a cert revoked and that the pr= ovided definition leaves open to interpretation the meaning of the many cer= ts in existence that lack AIA, CRL DP and the TBD extension.<= /li>

=C2=A0

If a cert DOES have an OCSP AIA, are you still free to consider it revo= ked in your processing?=C2=A0 If so, why is the noRevAvail different?

=C2=A0

[CW] You wrote the words =E2=80=9CMUST NOT use such information=E2= =80=9D so you would need to answer that one. Given you have elsewhere backe= d off that definition, i.e., =E2=80=9CMaybe squint so much you can't ev= en see the text, I admit=E2=80=9D was after your =E2=80=9CI prefer the language I first proposed=E2=80=9C with rega= rds to criticality, I will wait for a new definition for the new extension = semantics before commenting further other than to reiterate that I see no n= eed for this extension but would prefer a statement that revocation info is= available but no reference is provided if something must be defined toward= s this end.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--0000000000008d997b05b47759e4-- From nobody Thu Nov 19 11:32:23 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F8A3A1091 for ; Thu, 19 Nov 2020 11:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 f2kolPBF3ZIg for ; Thu, 19 Nov 2020 11:32:20 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC2D3A107F for ; Thu, 19 Nov 2020 11:32:20 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0AJJP5o4024220; Thu, 19 Nov 2020 19:32:19 GMT 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=mXLRxONMCMcAXKOO+mjIfHPVsaLKDZUEJvMLecPR5oU=; b=Zo3j/Yepvrfi+aiyWohSjyLEgVZD8htwGR11v+XrCFL8jnQ0Oh1hZBdJbArLzJBTL8uB exSASaGCMJEMaGVJ/DLkRE7PdRbcmoxmYjY2eErhwgymQvxMabMbZghTuykyRZieoLPc WbThjtG9K+fdFIuLX0B+OEq5hrRLH8hkOsjzwZHUBgMiRy/TsWGe7ncgnPZvM2muVvRx gnDqgG3lkwDSUzCeoJSKIJbOO1F9M3I/XTUNpoiOYLc24UPJJeesu+MHX/eMGFG1kG4A jCCE6Rz2pUXsvdB1FW80R7ykRYzWzp7otJAEhp24+MI3XGi4cn6nhWGM7gjUtDyxVW+o 4A== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 34w7praggk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 19:32:19 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AJJ4hWC004941; Thu, 19 Nov 2020 14:32:18 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 34tbf2w659-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Nov 2020 14:32:18 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Nov 2020 13:32:17 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.008; Thu, 19 Nov 2020 13:32:17 -0600 From: "Salz, Rich" To: Deb Cooley , LAMPS CC: "Cooley, Dorothy E" Thread-Topic: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension Thread-Index: AQHWvaQZXUTdU3NB3kG40d2h5AUTvKnOUMOAgADFv4D//9NNAIAAXMoA///G3oCAAIhggP//siKAAA3ddoAACGBtAP//8PMA Date: Thu, 19 Nov 2020 19:32:17 +0000 Message-ID: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <13005.1593208602@localhost> <001001d64c58$98890d40$c99b27c0$@x500.eu> <45FA4A1E-FC9B-4194-933A-A2DA1E8C14B9@tzi.org> <000701d64d1f$7a7cea20$6f76be60$@x500.eu> <2C938217-44EA-43DC-9CDC-9E2FFFF2EF58@vigilsec.com> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <877dqiazao.fsf@fifthhorseman.net> <910E0F57-02D8-439C-A42D-0B39148A0919@akamai.com> <33F97939-3CE9-450E-BE46-17D54BF01417@akamai.com> <615BE432-A9AE-4413-B9C5-C88DC1F15A08@redhoundsoftware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_DBB164D0464A471AADCC816FDC1F0FD8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_10:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190133 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-19_10:2020-11-19, 2020-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 adultscore=0 mlxlogscore=919 spamscore=0 malwarescore=0 bulkscore=0 phishscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011190134 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 19:32:22 -0000 --_000_DBB164D0464A471AADCC816FDC1F0FD8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHdhbnQgdG8gbWFrZSBEZWIgd3JpdGUgbG9uZyBub3RlcyBhbnkgbW9yZSwgc28N Cg0KPiAyLiAgaWYgb25lIGRvZXNuJ3Qgd2FudCB0byBwdWJsaXNoIHJldm9jYXRpb24gaW5mb3Jt YXRpb24sIHRoZW4gb25lIHNob3VsZCBtZXJlbHkgbm90IHB1Ymxpc2ggQ1JMIERQIGFuZCBPU0NQ IEFJQSAoZm9yIHdoYXRldmVyIHRoZSBjb3JyZWN0IGxhbmd1YWdlIGlzIHRoZXJlKQ0KDQpJIHdp bGwgbWFrZSBzdXJlIHdlIGNhbiBsaXZlIHdpdGggdGhhdC4NCg== --_000_DBB164D0464A471AADCC816FDC1F0FD8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDY4OTE4 NDY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MTY3MjYyMjA7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHdhbnQgdG8gbWFrZSBEZWIgd3JpdGUg bG9uZyBub3RlcyBhbnkgbW9yZSwgc288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyA8L3NwYW4+PC9iPjIu Jm5ic3A7IGlmIG9uZSBkb2Vzbid0IHdhbnQgdG8gcHVibGlzaCByZXZvY2F0aW9uIGluZm9ybWF0 aW9uLCB0aGVuIG9uZSBzaG91bGQgbWVyZWx5IG5vdCBwdWJsaXNoIENSTCBEUCBhbmQgT1NDUCBB SUEgKGZvciB3aGF0ZXZlciB0aGUgY29ycmVjdCBsYW5ndWFnZSBpcyB0aGVyZSk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3aWxsIG1ha2Ugc3VyZSB3ZSBjYW4gbGl2ZSB3aXRoIHRoYXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DBB164D0464A471AADCC816FDC1F0FD8akamaicom_-- From nobody Thu Nov 19 14:57:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3DF3A1340 for ; Thu, 19 Nov 2020 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=VDG+X4gO; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=IiSlINiB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beZycCXYqq2h for ; Thu, 19 Nov 2020 14:57:22 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32343A133F for ; Thu, 19 Nov 2020 14:57:22 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1605826641; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=cYxN3MBc6JlxYDfnEyQREt5THMygDaAzZ7VsfDxtbvQ=; b=VDG+X4gOowNldX+f2CjVVgK8rPQtOBZVQWrXsG1zgdzJ5S/AcPHsBVC5N3BtvfwJeFXx1 K/jHPgStC4WyfC7Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1605826641; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=cYxN3MBc6JlxYDfnEyQREt5THMygDaAzZ7VsfDxtbvQ=; b=IiSlINiBoA2LHXzBuYBxx/o5iagnD8KXhYhcKIhbUVCPZhIZmkfRUUW3Q+koYJCt+KmMX es2aX2p1a/EHmNcCK3fFHqximPzbKiUno6cN8D8pWeGmlMI82QUtjPzRDVGVG7REsvbL5VL rMxoOkvZPnqJLT+/zN6+0AueYKpN40b8jbcfYZZJiDfDhuAcWdX7YdOvMyRk9evRTAfLczY ip4qzfVZDrszAt6kUvJ7oy/xMSUqzKpCWaNkMrBxB69InIvdqFsmfVElFV9X6TAAKT0l1i4 OXl7nJj7+q71wDKXCLs/6/n1JNvc7R/1zzQigtygiz2LnJYM9ZjAWbXIYe0A== Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 8528CF9A8; Thu, 19 Nov 2020 17:57:20 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 99083206F8; Thu, 19 Nov 2020 12:34:37 -0500 (EST) From: Daniel Kahn Gillmor To: "Salz\, Rich" , Carl Wallace , Ryan Sleevi , Mike Ounsworth Cc: LAMPS , Santosh Chokhani In-Reply-To: <47F854A5-B48F-4238-9621-6E3511E53DBA@akamai.com> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <871rgrdgyg.fsf@fifthhorseman.net> <102d01d6bd0b$3a880150$af9803f0$@gmail.com> <33267B3B-4198-45D1-A7BC-BE9E282292EC@akamai.com> <418F8885-292F-4969-8A14-179A0675D8B3@redhoundsoftware.com> <2CB0AE8A-DF4E-403A-A939-34C6DF9106C9@akamai.com> <80BCA317-3282-4EF1-A698-F6241CCCFE22@redhoundsoftware.com> <38A9288F-A7DD-45D4-A267-913D52257128@redhoundsoftware.com> <405A0031-CD09-4A97-81DB-0B44B45A45C5@akamai.com> <3D3AED89-E29B-4377-95C7-5B371C9BEE10@redhoundsoftware.com> <6E12311C-B014-4319-BA12-08E18E2309F7@akamai.com> <5A0BF428-BFD2-49C9-9D1F-16AEDA69ADB5@akamai.com> <874klmay31.fsf@fifthhorseman.net> <47F854A5-B48F-4238-9621-6E3511E53DBA@akamai.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ== Date: Thu, 19 Nov 2020 12:34:36 -0500 Message-ID: <87r1op9ro3.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: The id-ce-noRevAvail extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 22:57:24 -0000 --=-=-= Content-Type: text/plain On Thu 2020-11-19 04:03:04 +0000, Salz, Rich wrote: > > [1] https://censys.io/certificates?q=zlint.lints.e_sub_ca_aia_does_not_contain_ocsp_url%3A+true > >> These are intermediate CA certs that don't contain OCSP urls. > > All of them? I couldn't figure out how to say "and not a CA". yeah, i think all of them -- the e_sub_ca_aia_does_not_contain_ocsp_url label only triggers on intermediate CA certificates: https://github.com/zmap/zlint/blob/3f689d276c06aad066b36967c4af3f75f6822247/v2/lints/cabf_br/lint_sub_ca_aia_does_not_contain_ocsp_url.go says: func (l *subCaOcspUrl) CheckApplies(c *x509.Certificate) bool { return util.IsCACert(c) && !util.IsRootCA(c) } Note that this requirement is no longer strict in the Baseline Requirements, given ballot SC31: https://github.com/zmap/zlint/issues/462 But anyway, this doesn't demonstrate a need for either id-ce-noRevAvail or ocsp-nocheck, right? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX7asrQAKCRDEDyVUMvKB D+CzAQCNR4euGuVySN7yPrSdzN3NXyAsufSjhnlukhBt1qFfRgEAjI8nYrkiGsIR RoqvWvU1Ewr2y6XS7hr/ScyhzEQCIgo= =otUH -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 19 15:46:52 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CD3A13B7; Thu, 19 Nov 2020 15:46:51 -0800 (PST) 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 EJwSxEl9nHnr; Thu, 19 Nov 2020 15:46:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FE43A13B9; Thu, 19 Nov 2020 15:46:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3C71EF40767; Thu, 19 Nov 2020 15:46:36 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20201119234636.3C71EF40767@rfc-editor.org> Date: Thu, 19 Nov 2020 15:46:36 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8951_on_Clarification_of_Enrollment_over_S?= =?utf-8?q?ecure_Transport_=28EST=29=3A_Transfer_Encodings_and_ASN=2E1?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 23:46:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8951 Title: Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 Author: M. Richardson, T. Werner, W. Pan Status: Standards Track Stream: IETF Date: November 2020 Mailbox: mcr+ietf@sandelman.ca, thomas-werner@siemens.com, william.panwei@huawei.com Pages: 13 Updates: RFC 7030 I-D Tag: draft-ietf-lamps-rfc7030est-clarify-10.txt URL: https://www.rfc-editor.org/info/rfc8951 DOI: 10.17487/RFC8951 This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended. This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Nov 19 15:48:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C23A13BB; Thu, 19 Nov 2020 15:48:02 -0800 (PST) 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 t6sr-2qyYXbA; Thu, 19 Nov 2020 15:48:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B573A1511; Thu, 19 Nov 2020 15:47:33 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 55060F40769; Thu, 19 Nov 2020 15:47:20 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20201119234720.55060F40769@rfc-editor.org> Date: Thu, 19 Nov 2020 15:47:20 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8954_on_Online_Certificate_Status_Protocol?= =?utf-8?q?_=28OCSP=29_Nonce_Extension?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 23:48:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8954 Title: Online Certificate Status Protocol (OCSP) Nonce Extension Author: M. Sahni, Ed. Status: Standards Track Stream: IETF Date: November 2020 Mailbox: msahni@paloaltonetworks.com Pages: 6 Updates: RFC 6960 I-D Tag: draft-ietf-lamps-ocsp-nonce-05.txt URL: https://www.rfc-editor.org/info/rfc8954 DOI: 10.17487/RFC8954 This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updates RFC 6960. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Nov 20 12:00:44 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EE43A1083 for ; Fri, 20 Nov 2020 12:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=I2iFJcXl; dkim=pass (1024-bit key) header.d=digicert.com header.b=rlRpOICR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV_ZKfIJT4yn for ; Fri, 20 Nov 2020 12:00:35 -0800 (PST) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B6D3A1146 for ; Fri, 20 Nov 2020 12:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1605902422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=lSiZSY7no59Y2GjTPP2AGnnJ6M2k3mnxq6lkpy+OiSg=; b=I2iFJcXlfWZSN9QZoPq9QvzVDB4mZ8mi7RZDM3mENa48hcCGD8oKlhkfCDmaqQ17Ock84w Mi8niX8jQUK6aNMWmgV26sZCjcZVxPMKURZjIsJz0NTvwrpkcbXE7NpUg4niRsFjXf6YH+ m8oT5zKvLly7tmvP/CwV/cgawTySHyw= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-486-i_UkDTxDMempxxEh4hvG7Q-1; Fri, 20 Nov 2020 15:00:19 -0500 X-MC-Unique: i_UkDTxDMempxxEh4hvG7Q-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YdT0K9lcaQQWeGJXDXJv/3SKqTKSE6w6WgRE/VqI++f7GmAa+957KXYiozvdtceQUWZQ33p2CgYOHeokM+hLi+svqRyvgzwbpTuyX1i7ZeEV4bWzGX9M8SJiMf0ooTr8Wh4WPZwUyFCL6bhweiSqky6K7dIwOEfnQ7kPI0pkdSUMSirUFw+W9w2g/ZEU3vK0zu6bqLkvwzw3lhVKrEJsMAKGmAlIYO0yITagy3VOV6dg3z7hMmpImFaLe++Rdv/Pgnx1V3KF35dfEp/TFGOgZis0qSILEm3FDZg9UH3q5IR7WbFvvnb94ATa2s7/niRNBUC7BlgKEilrRQ7uOtwxDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lSiZSY7no59Y2GjTPP2AGnnJ6M2k3mnxq6lkpy+OiSg=; b=ZM46FT7dA/TkXXWRxjHznmCHkbrgBUEL7ApezhTzbB7dYLwIkoLSpRE434JOyeiB4p+ksbkPM9O1R2iMfzgL4hoX8W/Q8fqJn5Xw86gyweqB3bwhh2YbcbxE7+xLM4nMWm5pfXYya/6lOtoTSQIohl2vJZ0uYzLVqpgR01YDDtr1tTsi+ibf8jBChmRzWe0c+0iHOnnPVRjppSFbuWP5DiOl5FtDZvwx/DmIJlJZ912T0SIvbyi9+jIJzGUxRltFvgUqezXvw1aLKOh3pU0QuxlDec0p9S65D6dI1ufE4FSYZKkgf8xXZAkY7uCbzd33HVCpncR2XbPf04MfQ3RDvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lSiZSY7no59Y2GjTPP2AGnnJ6M2k3mnxq6lkpy+OiSg=; b=rlRpOICR+ZAK3DbDx1vjxrAN0MkpAwHkAwFUXLWpwLcNKu1qbfEkyujye+4DpfuqoniiFih197GcBJHzkHnUYOIMZzK/4T+Yd/lclL60SVJIihpRc2hJTItCWmQGX0vAXl8fRL4mxISxMmE6QOygIieUEuCB5EIdxr3pssBfwjc= Received: from MN2PR14MB3167.namprd14.prod.outlook.com (2603:10b6:208:12e::28) by MN2PR14MB3488.namprd14.prod.outlook.com (2603:10b6:208:1ad::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 20 Nov 2020 20:00:18 +0000 Received: from MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82]) by MN2PR14MB3167.namprd14.prod.outlook.com ([fe80::e1ea:51bf:a4b0:2f82%7]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 20:00:18 +0000 From: Tim Hollebeek To: LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-crmf-update-alg Thread-Index: Ada/claNYwRy3JmDRXS5UlaLVNU2IA== Date: Fri, 20 Nov 2020 20:00:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=digicert.com; x-originating-ip: [74.111.113.115] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a7a1977-6a99-470b-0197-08d88d8ee799 x-ms-traffictypediagnostic: MN2PR14MB3488: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wNPWJnoVK6Su4oOfHiZseuS+S/jgQ2PVB/mPnHvFKrMf8Lyc7Ce4nAbhj5396/rw3nNUpHJyincPKFSmMFE+iTl+rY8vdd4VT9v3mlz5PjLMRPHLoxNJBEiDDqiDuebQ7pgPTQJEtwqGPXQybKJENnaKH8s5OpY0zh8scjLRekODFuHIJdS6rOUssi7bDH/1IjVHuHuwRvYYRMNvA4OBn/AuIzJXfwe/+sT8hemZaN9q/rg7Zx51fTpleqXzjUDARaNAPhlaIx1x/OMj99X/ph3avyOSQLiiz7ik/UrYbd98bZ3ZN76KGNe96UXb3C/2d9AoXXf6TVmq8q+ll5gAec5gZq1AOFdQqAc2dhcK5d18/xKJ10NplyqWJj4ksFdaTCR/ksYNZxnPlcDtOinFFg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB3167.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39850400004)(396003)(376002)(346002)(83380400001)(66616009)(166002)(5660300002)(15650500001)(71200400001)(7696005)(66476007)(99936003)(44832011)(6916009)(2906002)(478600001)(52536014)(76116006)(64756008)(966005)(66446008)(8936002)(316002)(9686003)(86362001)(8676002)(4744005)(66946007)(33656002)(186003)(6506007)(66556008)(55016002)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: dwSyVVdQpOvcK0MiBTgYOtKwsCp8LZe661EzEXZa5e5WN69jZP0LAhGzKvFcoj90WjSeF8bQ9oGmGhnQ/ki0J3BGHEK+cLU4SxgtYq6bIzHpZP9ftyqZEk9UFEET+UVwjc5aLBw1et548MPnO9ySYWJZmTv5WfYHxsIkNXM17Q8u8o8J1qa3yfD8IE8foXhCPb6Oaw96mVA1Y0mEDZvNEIQr9AJUGSh6vWbfouisTp4kqDRPJlNCeYwE6MPbCI37E0rSoxpbOKIhUJdto/LF+IoxU0k5E72n4h1Ab/SsI8UnPO9eOGi5FcWk/PVyaOsxTc720NF4nrH1FKdJwsDEY/XSMA4MXCrjyoSnkwEW7i9PzybB1J+FzSDwUaTaEQOeEyNgp99BMscs3pynj35SOu9D06Cu9+8ss0pPVpaGcn7zZ7SMkRHSpCzckfV4rcVtlUs1qKdW5a8xJuoqFMvV086atVBTHEVZbBjx8StlVPGqmO6WFOpBAsPKhlTqVZg0vIXMzrxkyGrNYCwLu8kspiTt+P/ahwqOtkYGN52EWiLoVMUlSpdKKsIvnG021KO3Ktes44qtgYN1jFcy634oUnxeiBjJXYVS6z3HqM5CZLGJSRFD/Hq6Qp012zU4RZ1K0+GcF+zNgwOap9mgxSmZUfy937CfVP7BX9DEB9xEoCtZIZLSHYkLkzb+O4phg7TD7O0qFfJQlZlurCuvJMZj3Y52kgaQQYRVeCkdH+EoJIiVTy6pr1xkKa5MFQlYPAXMe1BwABwSuLYcqIXZNFrr82uRm7Z9yuGGc97n2PHRviBofTiZzj+RwqWkh5L9KO2FXMSayEODirdag3/NDQLpl1E+ZXDTriFnF8mweDhRrCNgtUx7S9GEB6QdOHLuq9zNRSrXtKL0XwDh4P9JmJ/YtA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_043F_01D6BF4D.D9B76470" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB3167.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a7a1977-6a99-470b-0197-08d88d8ee799 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 20:00:18.2402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OOWSL/edBgb/ftbw2CoaBmpQ/ClB52zUp+L0wDmK/u4U5IJyUgA+0RzTPhPOPVx64hv+sZTNgZmCV/23qfBiDupGjLbGcUeirhoFAmEJnbE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3488 Archived-At: Subject: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:00:43 -0000 ------=_NextPart_000_043F_01D6BF4D.D9B76470 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0440_01D6BF4D.D9B76470" ------=_NextPart_001_0440_01D6BF4D.D9B76470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We talked about Russ's other draft earlier this week that adds more appropriate modern algorithm choices for password-based MACs in the Certificate Request Message Format (RFC 4211). The draft is here: https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.txt Please indicate by December 9th whether you support adoption of draft-housley-lamps-crmf-update-algs by the LAMPS WG. -Tim ------=_NextPart_001_0440_01D6BF4D.D9B76470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We talked about Russ’s = other draft earlier this week that adds more appropriate modern = algorithm choices for password-based MACs in the Certificate Request = Message Format (RFC 4211).  The draft is here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-crmf-upda= te-algs-01.txt

 

Please = indicate by December 9th whether you support adoption of = draft-housley-lamps-crmf-update-algs by the LAMPS WG.

 

-Tim

 

------=_NextPart_001_0440_01D6BF4D.D9B76470-- ------=_NextPart_000_043F_01D6BF4D.D9B76470 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMjAxMTIwMjAwMDE0WjAvBgkqhkiG9w0BCQQxIgQgtmnqtg9epwb7JFITqvz8z8x0VFeP prwAvHig5rcf4SkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAEjBA13REJEnqzQAVFzeckCXlJF75Y9cy3fxwYMuG2lDrKPVIeRJ8/AtW9t/8/23WuzIlFEk 93kRfDRYaOrxF4esFdDCtUyYwyXWeF1AtB3tzYpAj1HDtUGNEoKKPqikAYfccdKgzWRF6w4q+N7d 1CJBoN45MMQDTox46Hw+YB1uURAxj289EdImJ+YeTevcyaeYHUbMPcyofnJgXL2z0J2GpiYxF4WK 0P5DJQUmlXvZ5wY/AyLn7RviV+rWG2z6tgKsLjCOy3F3D53N9jUaz/qUNdvjGWacKLRFvIB2SsWh L60RdoiuIl70RCQadtRzTpXcHWj0tinhSTJGdYlsV/QAAAAAAAA= ------=_NextPart_000_043F_01D6BF4D.D9B76470-- From nobody Fri Nov 20 12:15:24 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019623A1144; Fri, 20 Nov 2020 12:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 jz1tTwkEMrWu; Fri, 20 Nov 2020 12:15:18 -0800 (PST) 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 27C663A1133; Fri, 20 Nov 2020 12:15:16 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AKJwNaD007967; Fri, 20 Nov 2020 20:15:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=e59b+UGWKMLfydy8UpZoS59qSG5awupZTt4k/yFrLVs=; b=fAtgF3CnNuBkmBXZy0LBLng/i5IA+R24OzaSYFpJvSIkWYngCQZ4v4v155Pth1+y3TGo L0EqDMnO+6uvMQSK/Ov4EBU+uwUgOzgjuetU9e2kaDq2Mrn+nG8vrGeZk3avNHW9hePW ukYA4b2BwpVvuBkqQJkjFbNv6f4azMDK0M3Vhtz+ConaknE9JeWPf5Mi84Ja2XQ1uDH2 ucmOhE3JvaZHJWNj/B1sn2SmkB/2eVg4hlieU0HlaJy4Sz0ZAWaVGeV0VScZ8RKd1DUc HXgoyKrv3LzDXBKInPeMtOR/J02mdZosLIT9dW2lmBdt9iD6QEDLmDkJ/TAV3zAb4/I3 Lg== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 34x1hqxabf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Nov 2020 20:15:15 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 0AKK4cV1010258; Fri, 20 Nov 2020 15:15:14 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint3.akamai.com with ESMTP id 34tbf351e0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Nov 2020 15:15:14 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 20 Nov 2020 14:15:13 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.008; Fri, 20 Nov 2020 14:15:13 -0600 From: "Salz, Rich" To: Tim Hollebeek , LAMPS Thread-Topic: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg Thread-Index: AQHWv3naugviO06hMkuyLJOrbOpZfQ== Date: Fri, 20 Nov 2020 20:15:12 +0000 Message-ID: <25B50CBF-A82D-4F2D-9CD2-73070183A2C6@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_25B50CBFA82D4F2D9CD273070183A2C6akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 mlxlogscore=878 malwarescore=0 spamscore=0 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011200135 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-20_13:2020-11-20, 2020-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 clxscore=1015 suspectscore=0 impostorscore=0 mlxscore=0 spamscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxlogscore=796 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011200135 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:15:23 -0000 --_000_25B50CBFA82D4F2D9CD273070183A2C6akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaG91c2xleS1s YW1wcy1jcm1mLXVwZGF0ZS1hbGdzLTAxLnR4dA0KDQoNCiAgKiAgIFBsZWFzZSBpbmRpY2F0ZSBi eSBEZWNlbWJlciA5dGggd2hldGhlciB5b3Ugc3VwcG9ydCBhZG9wdGlvbiBvZiBkcmFmdC1ob3Vz bGV5LWxhbXBzLWNybWYtdXBkYXRlLWFsZ3MgYnkgdGhlIExBTVBTIFdHLg0KDQoNCkkgc3VwcG9y dCBhZG9wdGlvbi4NCg== --_000_25B50CBFA82D4F2D9CD273070183A2C6akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NzMxNTQ0MTI7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNzY1NTE5 NDQgLTM5MTYzMjAyNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaG91 c2xleS1sYW1wcy1jcm1mLXVwZGF0ZS1hbGdzLTAxLnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv YXJjaGl2ZS9pZC9kcmFmdC1ob3VzbGV5LWxhbXBzLWNybWYtdXBkYXRlLWFsZ3MtMDEudHh0PC9h PjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+UGxlYXNlIGluZGljYXRlIGJ5IERlY2VtYmVyIDk8c3VwPnRoPC9zdXA+ IHdoZXRoZXIgeW91IHN1cHBvcnQgYWRvcHRpb24gb2YgZHJhZnQtaG91c2xleS1sYW1wcy1jcm1m LXVwZGF0ZS1hbGdzIGJ5IHRoZSBMQU1QUyBXRy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQg YWRvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_25B50CBFA82D4F2D9CD273070183A2C6akamaicom_-- From nobody Fri Nov 20 12:41:40 2020 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 86AD23A1145; Fri, 20 Nov 2020 12:41:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160590489853.27785.17959978489136502732@ietfa.amsl.com> Date: Fri, 20 Nov 2020 12:41:38 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-housley-lamps-cms-aes-mac-alg in state "Call For Adoption By WG Issued" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:41:39 -0000 The LAMPS WG has placed draft-housley-lamps-cms-aes-mac-alg in state Call For Adoption By WG Issued (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-housley-lamps-cms-aes-mac-alg/ From nobody Fri Nov 20 12:42:06 2020 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 D48453A1153; Fri, 20 Nov 2020 12:42:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160590492485.7445.1626989732836950443@ietfa.amsl.com> Date: Fri, 20 Nov 2020 12:42:04 -0800 Archived-At: Subject: [lamps] The LAMPS WG has placed draft-housley-lamps-crmf-update-algs in state "Call For Adoption By WG Issued" X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 20:42:05 -0000 The LAMPS WG has placed draft-housley-lamps-crmf-update-algs in state Call For Adoption By WG Issued (entered by Russ Housley) The document is available at https://datatracker.ietf.org/doc/draft-housley-lamps-crmf-update-algs/ From nobody Fri Nov 20 13:14:56 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05D53A0659 for ; Fri, 20 Nov 2020 13:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 uw8rESib8sfJ for ; Fri, 20 Nov 2020 13:14:53 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150053.outbound.protection.outlook.com [40.107.15.53]) (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 280BF3A064E for ; Fri, 20 Nov 2020 13:14:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DvCv76zocZ78nbsoHEcRNY4X2Q3YU7qjn2vNejq8SrJQDBFFB34iAHjLy6/jgj6EqL8tasiy4mAOWdrsCq52L2cvrUlD7vsV2LcWXw5Vhn0JrYzS9bhFM/UPmtgjSKYOBEe+cY9kb0b/2oPczEmeHQHJOMpkrd5ePWDep74rnaEnMEBD06ETD59E87OdF1QAH3Ute0dOb514K51XC39LDf/TDPGFJvoWltNV0PlkVzLGVoWeeGPAwsOUbFgb0qR0ZUP5hDwl+06Qd879dInTKGc8YaDez+wPJzD8gl+Aeb6jnumcb1yrdo+9B/hcyDp475ipekAFxmFshAHaoq06ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MdUUrR8zF2KX2CGwtvXedExTeprMi/jlxLIeVXxgatc=; b=jViH9p/fusq1Zk2xzqhI8qfNn+8CP+fmlIxDwX/Jgn9vOvvp0lxj42DuuU57p3Gw6ld4maoFnrxh34IxZ/ZWXJP3GoZBAtrIahy4o1OdyIHXa0pC7lxydgMsKvOuQOfK5x7zmMbSYzrqFvndokWh5V0YWLts8t9kCcZIGYMrUZdo+hI7Kc2jb/nb6AMC/M9dgwMkZJKMc/XhpnerM2A3tY6wbYuAOLvnvqaTF4NMbMOmvmJX35LKJpAKPZisodaSEYH40AKT8uN6cpIOACXB/Ez1Vm3bNsbRIyUBNAsG01kiiaOEN0gnl5Gr6QUuXlpqpbsyYGIlW3CEJShuqdqdcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MdUUrR8zF2KX2CGwtvXedExTeprMi/jlxLIeVXxgatc=; b=NLU40JavrPid69wozKq5FIgerIuUBtsggJOr4zkWhIReCC5QT9r2rXN8bVccTutxYV7hz4JgHwHdlWfzdEpinPWi4HPRUYfAKk+5p/FGGJzpE/WC+NMKhVYP/GDjk4f/WkrjC1oEbB4XCJb6KRisCYTQgDHUbWVVyGE3oSDj/YA= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB2211.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 20 Nov 2020 21:14:46 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.028; Fri, 20 Nov 2020 21:14:46 +0000 From: "Brockhaus, Hendrik" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-crmf-update-alg Thread-Index: Ada/claNYwRy3JmDRXS5UlaLVNU2IAAD8QLQ Date: Fri, 20 Nov 2020 21:14:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-20T21:14:44Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=cda61531-67f1-43c3-9174-c49e0494749b; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.163] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a3f98bd6-b228-4848-10a3-08d88d994e8d x-ms-traffictypediagnostic: AM0PR10MB2211: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: spWFyF4BYIoafD2+2kYeR5o6ayqbjcuFAeh1OQxGkf/ZgG2yvJKP3v4GebQUiTuj2jSUiWreufpvPPiQ9qi96VFxyApmYKccaU8+6DMkf9Z4N8Q6ShEikDAwn/xgtGuhE7pJ9ZZCilVlZBOk1zvWoHORBnR4E3LYxSxVY1m8To0RWCL8leqbpfVliMPaYLD7J70ZxkEwri9mFwXUIJi3qMwMCeRdYclx8nfqA820Mq84TQor1fZspJAFuW7VNKReh2Vd6fgFb7Ty3B92hn6ZHVaEpKzk+NluB4LWDDsgf9hi5rzknirNBeDSM8RBjub/dWO8idEGLtK4zxynufr2kiUTRx4zk0caeV8+1T3cWDq6alx8HV+nekFdY/UeRHoQ1BOlXY2ucl0THaers4VMaA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(346002)(376002)(396003)(2906002)(5660300002)(55016002)(76116006)(66446008)(33656002)(4744005)(64756008)(26005)(9686003)(6506007)(83380400001)(8676002)(66556008)(55236004)(166002)(66476007)(8936002)(478600001)(66946007)(316002)(52536014)(15650500001)(966005)(7696005)(110136005)(86362001)(186003)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CeRYRiC3oT0W+Go73IimTJ7tGaDrZSMIl7VZ11A1MN7I1qvshVmy5UNM1jxUCWWMyhNWeOC6SevVEKXHIeaxhlWV+ntWN30qEW+Gbn7Fklcuo7RWXDEe8IiyFCBuv476n+/34FKpFYJWm2AL45WEfSC+XAF54Qon7JkZImO2CCOXVx0wa3Z4U2oIoaYEiN+rUw4ywQu3DtrdIs1x0MeX8I3WYjXSKTjW4/VMhjL/Ql3olmAaoaNBhYQYIPcP2wKSs/MBsQNv5S/awMH7VFTCd9dB6N1QItVlQ082FWwGlxqJr7XVqm9ryxxYsRdaffK+LFNUo73z3J87BhmA2R9CPm6zkAlWtw5h7AyEvo1m4uIesnS4BussDjls/Mhd1BnLqQw2/rl6+7zcYNoEMRJCVri9XV92YgBvobe/J/ORK6ywwrwhHZA2Ajf6bbLp+OV+RGp0zUm9a8/W2wz88w3a4QyToO5/323FjxopP+jhWtjIIpVOutYbZht4l/pbM4DloGUUMt0LGip021/esk8ch6Xs5Vz0IKTS5S8ZjNccsnwpCJRzyGu9sQOt8HnHZSgWx5ChSq3Xknt3IQwdi+gCeI2qLOLRCZXiVjTN0pLHyU6TpW8TmWMmm+J9GKVTeVae85F5wMy1SFZPFCxsOgZV3Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR10MB2418C5F4110D839445E7C19AFEFF0AM0PR10MB2418EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a3f98bd6-b228-4848-10a3-08d88d994e8d X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 21:14:45.9296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7AMChxXG43NFtNUXBtbfTVU0EjrdCvDyTkxTUDU6kBOh9+O15zOnHx02KQ9KcRFINU6NCL02PKJiMjqbFHJ3NYhi356NwVxFnNE+cHmMJ9M= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2211 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 21:14:55 -0000 --_000_AM0PR10MB2418C5F4110D839445E7C19AFEFF0AM0PR10MB2418EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Von: Spasm Im Auftrag von Tim Hollebeek Gesendet: Freitag, 20. November 2020 21:00 An: LAMPS Betreff: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg We talked about Russ's other draft earlier this week that adds more appropr= iate modern algorithm choices for password-based MACs in the Certificate Re= quest Message Format (RFC 4211). The draft is here: https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.txt= Please indicate by December 9th whether you support adoption of draft-housl= ey-lamps-crmf-update-algs by the LAMPS WG. -Tim --_000_AM0PR10MB2418C5F4110D839445E7C19AFEFF0AM0PR10MB2418EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

&nbs= p;

Von: Spasm <spasm-bounces@ietf.org> = Im Auftrag von Tim Hollebeek
Gesendet: Freitag, 20. November 2020 21:00
An: LAMPS <spasm@ietf.org>
Betreff: [lamps] Call for adoption of draft-housley-lamps-crmf-updat= e-alg

 

We talked about Russ’s ot= her draft earlier this week that adds more appropriate modern algorithm cho= ices for password-based MACs in the Certificate Request Message Format (RFC= 4211).  The draft is here:

 

h= ttps://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.txt<= /a>

 

Please indicate by December 9th whether you support adoption of draft-housley-lamps-crmf-update= -algs by the LAMPS WG.

 

-Tim

 

--_000_AM0PR10MB2418C5F4110D839445E7C19AFEFF0AM0PR10MB2418EURP_-- From nobody Mon Nov 23 03:35:14 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802EC3A08D6 for ; Mon, 23 Nov 2020 03:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaIvewil0CgH for ; Mon, 23 Nov 2020 03:35:12 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2123.outbound.protection.outlook.com [40.107.91.123]) (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 D4C153A08C5 for ; Mon, 23 Nov 2020 03:35:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jmpmk9p0LRyjMv6uNvgCcl8urFRVhxlFuIsrxy5nWBpK4PdDKBlAGmc8frJtvpTl7oSsCPqJKOcG1L7BxvZOFnaoNopH11K5i1R/w5fjELHcN5ji/SKpulsVo99+6ri5kNloma5lvTw/WVW2I14oVvBLeRvQ54qYt0lIkXsoXG1cWPcTIJLYaKNbZCUih52f7DMquad5yCnQVfVti912HW+Nb0tznRg6sBgZWTR40OIksiN5HN+t2R9eETf2zpivzlE3fCdQpL7rFV8GhfeleYIUCcW8KEQX027cDlrpO5fNGFUtQcXYYAWHJlRK++joHjNR/GaUv6wJj0e5aDcvVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LxYmqb2v5nJ4+7kHPtiVw8jjPel3v7VkWko0oezJ6sw=; b=BfufRyVlHMh/nWe+lyHin/mNuDHjd4O9l+vJZ34RPA4ecuAuZkel1CAOmc1/IO7qLGryJluEjut5537mDKmCaZjMefz/uLLoF7x3mPvt8oo7uHWJ3oJFg2RpSWSZvyLbx3V20NPcumBOC7ALOlmCQRszBb6ASCDRBPn48sjUijxt8wQehmfjPbNMO9spxmn0aFT0QZNyKErIS30zKRVJ1bK8WucOkXv65xV3kjvGT1iaErzSGnrikmp/f0fPXBPlnMv0Yk2oxYBTmma1lhpQFfBxTn0bv33sfTEXPNEPxN5T2m2wsfEfNdCJxvkKtRTcePbpKeQLEJhyDjZxLos+ug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LxYmqb2v5nJ4+7kHPtiVw8jjPel3v7VkWko0oezJ6sw=; b=Sb8gkA4Nd+LqAOLrjrgV2k0GbqtvYlRdbr78AT6FJHACSi2F4zmFjnvBeMyqZccPPJwjYJGbCm46rhQBo0gl+4mMKjQB0wK4PYMxsdhOYhOKUSnPO3hPsXCqZG0xTAJlgVFc6Qk7Gk+YfqGNKuEu9oxHJN88c34wVwhPSn4NI3Y= Received: from SA0PR09MB6841.namprd09.prod.outlook.com (2603:10b6:806:7e::23) by SA9PR09MB5344.namprd09.prod.outlook.com (2603:10b6:806:42::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Mon, 23 Nov 2020 11:35:10 +0000 Received: from SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::7986:be41:74dd:45fe]) by SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::7986:be41:74dd:45fe%5]) with mapi id 15.20.3589.030; Mon, 23 Nov 2020 11:35:10 +0000 From: "Dang, Quynh H. (Fed)" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwIT1DWr Date: Mon, 23 Nov 2020 11:35:09 +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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:222::f] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 25663891-a741-4b7c-e281-08d88fa3d5b9 x-ms-traffictypediagnostic: SA9PR09MB5344: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dEB/Gu6v2Lue29es/pVXnqceK5HJdO4l9M42cwXeCQBRgybe3or3k9uCEbbZWxHPhaa29YC2DJ9GwpJSTtjUXUNxVSEtKGvR/W1XKnLo/uXDRprV1TE8TyShLs4MTpnRgSzm0MD1byYjNXZoes4Rnh6t+4I/lVVFZUFa0C8cPcstWWBNisIArOvi+HB95mzyFzmVYTskhpD2sqlL/YlXTpPJ90ah3385EiJpgc1rSq88ysdYPlUCGGfmdnkR1Q8lyNgU+c5Hwfy0dEHKe5UzdJjx7FYJJU9LrWzwa+wz9BEThJKj3u+sHm7mZJGyUtcMdpck/PmCUA1y23enKoveg8xTJiY7BlJsLlu5Ox4nOuI+RvQ3c6xzJzdJ/K1dachVJkgy3bZnrTtfjQphKJtbTw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6841.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(396003)(39850400004)(376002)(366004)(166002)(33656002)(91956017)(7696005)(64756008)(76116006)(66446008)(8676002)(110136005)(66946007)(66556008)(66476007)(478600001)(52536014)(316002)(4744005)(6506007)(53546011)(71200400001)(86362001)(9686003)(2906002)(55016002)(19627235002)(8936002)(19627405001)(186003)(5660300002)(966005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: PwPa4wJqTqNPTKIaQM3koziiWL8PocXIsUqKpIeKAFvqrGa9cv5diAAOlT6omu0T15Ueyamov6kYBGI5xoonqhNVjx3n34DZyZ6lnZRpw+UskpsKcL0L/NhGDVDWYvtRKaQEHN2gVp0iKRqLgfG0GtrxH2a1lfPcipXECNQS/KTIFKArkqreTy1tzfA/T07eU0AXsMB2mVDPdbViBA5naLRGuQwjoiuF/wxG5tW75SPgSAjSRP4wumRugCU8w4OQgynIjIceuopSIv6uYTFjHZDEJmyVI4ikbz5cxvqjmqp6O6mbzru2eM1WUbrlqUZUH6rMI+wH3kHrrNgst5hAL+zhfSKMZYPAhRp8hkOSvr1ij4OebFyYGLz2LIJLUKPt1zi3zqqaVQegA7EONhBIYEXY2UnbHuXfgPRay7/mqkUpHSMvlh6vFi9D/jjBJnZYUk6oBl1XVrHxnI9IvVy/s8Nu2V3dVvRtQJnegFI/uMH1xuz0vJKjfFdyOh/NkEz8hINsHr1C2p7K4I0QSb2RiknLxPZU54qHOTCeMXg6bc7lFpaai0ybCljyY+SJQDaMajbDpHqrHZJ34oD/4AtAMeC4CI4o+ZNjEl6SBDko5qI88yIxCKEENNt9NHhyOUanGNw9hm34oUm7n8I2XWsnjHAlO0NcwwFH/j3jA0J//eiyKcSqmsMrVSn2Ol8W6Y+Nn288McjJUcrPqD77c58w5xJj4oylKhcMdRt33koTu1zMtZrulYRe8g4pyCROgjsdmfbwL+2OJzFdAie/t2EEqOMh7uF3XWlbUTtdi1cuPb9aFKw2s2pyKHZt8DWxkgVTEjtzV2+22lXLZOspUWc/VG3JNvDqqPxoDdMPx/yTxPHtSuc5niC5ANVRcMo1kKciMRX92JFmccOp3B1m2+zGjVNY0fpjnz7ntG4VO1frre4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR09MB6841F9DD0D78565E7B61B86EF3FC0SA0PR09MB6841namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6841.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25663891-a741-4b7c-e281-08d88fa3d5b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 11:35:09.9851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xWTLMaz02yC6tw/YNTOGd8ctvCuvqzRfSPm/dPyFVh4EIaDZjF3q66zUcT/iDSBi X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA9PR09MB5344 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 11:35:14 -0000 --_000_SA0PR09MB6841F9DD0D78565E7B61B86EF3FC0SA0PR09MB6841namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tim, I support adoption of the draft. Regards, Quynh. ________________________________ From: Spasm on behalf of Tim Hollebeek Sent: Thursday, November 12, 2020 4:51 PM To: LAMPS Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg For those of you who are following the discussion, you=92re probably aware = of the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use withi= n CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<= https://gcc02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=3D04= %7C01%7Cquynh.dang%40nist.gov%7C22ecfd8d3ac5419324da08d887551f7e%7C2ab5d82f= d8fa4797a93e054655c61dec%7C1%7C1%7C637408146998624205%7CUnknown%7CTWFpbGZsb= 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C200= 0&sdata=3Dpz9%2BHetbufARZxSdREzwWm9EtQWcfG8kUz%2Bstrj70Qk%3D&reserved=3D0> Please indicate by November 25th whether you support adoption of draft-hous= ley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim --_000_SA0PR09MB6841F9DD0D78565E7B61B86EF3FC0SA0PR09MB6841namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Tim,

I support adoption of the draft.

Regards,
Quynh. 
From: Spasm <spasm-bounc= es@ietf.org> on behalf of Tim Hollebeek <tim.hollebeek=3D40digicert.c= om@dmarc.ietf.org>
Sent: Thursday, November 12, 2020 4:51 PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-ma= c-alg
 
 --_000_SA0PR09MB6841F9DD0D78565E7B61B86EF3FC0SA0PR09MB6841namp_-- From nobody Mon Nov 23 03:37:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E293A08DA for ; Mon, 23 Nov 2020 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_GOV_DKIM_AU=-0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPd2aO9P2wYm for ; Mon, 23 Nov 2020 03:37:19 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2105.outbound.protection.outlook.com [40.107.89.105]) (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 3B7383A08D6 for ; Mon, 23 Nov 2020 03:37:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d15sTSEB7W/Jwx1td/SOepX74qt5xi3vpBQC4eabpGLAFLNwO0rgKvboMyHlZep9cUss5OxBuUXvzwaY6jKYJVWViH1L6PS4EjQcgUwMGlQJrbAEgMQHYg75eZk/k8I+aJlQuWFfTCpXwrfHhOlOMA98lvB2ZUhfZqhsuPeCyOexbE8FddwLVLyT/ypKsa3OLIzzJGfa1rni08Yx7bs0+4OVQR94yPEuZoowriZS0oD1f3MjL7Pgh4bf8q6FJjZU7425Rm9VoInB/DJk6w8Cjh52STqYBBggLoIC7SZ9lodrn60Z1fyvhAzeMIL0Vy7pAZpIq17Lnu3ArR7mmfTv3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9PaMTmz4CVAFXycERk0VUSHIlRxsAaevbXsyQa1p48=; b=M2mORigk8UW2+piauaGEYARtrTjUI6ABmkI1Qo9FeSp53oFpSZpiFPHnF6aUKD67ABDJ4gwcPTlLdx92a1NieEgOuGgL3igT7nakWYdgqS0Sn0rXTHueUJaC5j3dh2xLPDq6hshH2zunDmdd9CHdsW29WuF874Tm4I1gnaJxi2bGnCMJZ7kVQtDwJGYeOiehTI1aR8xT2p/Yxy7p0PS+3aIWFDuPp0pTl5bHTB58ZML3rdvMw7o+YghSFEeGDOOcDXTP042J6/1Fi5GTGP1Ywp0L+d+c/V7fWttWIYDlbehC9rAGRq64Eh8GsYuMWnfcc6Ow9OK5DGtqIEf+rc+tVA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q9PaMTmz4CVAFXycERk0VUSHIlRxsAaevbXsyQa1p48=; b=qAUw5miEQLDU11HCMBy/0aYrtauxvcBA6YNwRct40DHApNrTtOVZ7h7soNN6+GfpWRQUu+8PBun9W3LjW4NgVFNMsW7TMiUGK/5jBVt2Pj3ZmPg9Jib1QzZVzSuYJczElRuTlFi4b8KcYauZ42c/4+qNhPfvyKC2PFAdVxhP7lE= Received: from SA0PR09MB6841.namprd09.prod.outlook.com (2603:10b6:806:7e::23) by SA0PR09MB6602.namprd09.prod.outlook.com (2603:10b6:806:ad::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Mon, 23 Nov 2020 11:37:16 +0000 Received: from SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::7986:be41:74dd:45fe]) by SA0PR09MB6841.namprd09.prod.outlook.com ([fe80::7986:be41:74dd:45fe%5]) with mapi id 15.20.3589.030; Mon, 23 Nov 2020 11:37:16 +0000 From: "Dang, Quynh H. (Fed)" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-crmf-update-alg Thread-Index: Ada/claNYwRy3JmDRXS5UlaLVNU2IACGppJO Date: Mon, 23 Nov 2020 11:37:16 +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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2610:20:6005:222::f] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8087e4db-ffe7-41c6-4c34-08d88fa4212c x-ms-traffictypediagnostic: SA0PR09MB6602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K6CtQU4yQK3ioxOVHXMeMzFIfQzzldx73ZIr7a83B4PWyjp7rSfaewS7joyvaSI4XIv7F/BXajEEtnpOqz4cdPnjqGQnoyXTca+xlIjGw6OP3RrZHqZQ0ADMRsSEfH/pMrAWjI1jQEQFzfoqWFPb+pKUgxYtd/pvMcAs0n3HsmTOP39Pq+/kgsCvesxwvYH+puSFPaGOMgsYK8S8sLiPSmGRkBj8ex+I4unhdGPn/XyYpcge/VHLmBpbMJYOD579RV4PhZlxDa996IKI8kaF5oS/2n8Va5CtA3u6BebLoX0QVoaAwWuAaaWhbtlGBX5OH8c/jRzUnuxCTFK/ozbKWQ8BYtrKj1RjqMR3XCChSZLDzB2EYd2nBDIcJFYMNOPG9fA3z5YpMycO7rCXb+Gr3g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR09MB6841.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39850400004)(136003)(376002)(366004)(110136005)(33656002)(19627235002)(19627405001)(8676002)(91956017)(6506007)(83380400001)(55016002)(71200400001)(86362001)(166002)(9686003)(76116006)(15650500001)(4744005)(64756008)(8936002)(316002)(966005)(66946007)(5660300002)(66556008)(2906002)(53546011)(66446008)(66476007)(52536014)(478600001)(186003)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: u8Inwpv8C/kdlggMV/q2R+aC7wq+de3wCUa972CKOUNijrxu2eszWtJmtDCLtdfqTP8asH5eH2QZOO1t2jcAyrBF91IGMiveSLvjhdyxzv/pW/8utvfs8Z5EB+k5s28HoVVyhc89l5vRXh8Cy/TvnEqd+H4HMya1NOuLgO5MizuChrtw4DG0B6r3KMuyK3oT3GOhP8oEzym+hz4DSoKygnEKXOHxA27gTE9iZCmAOWKRD9jTAEL6KGBcqZj2h7csOxp6QvPtZwCTLdYgI5/KOxhFlrRi31xQBdynv+oZxYa3fo6n7rKlu+wNqdAhk7jL+TZaty7EBHpcfdAEJIaI64+jepVhHNYoeN+PvloQGdhoz93yPXAGzI51LMvCdzRhtVrJmXCS0Pfpzm3zH5h90MBqfc6L/0qWd35wwDhaFw5Ie6bhhsSRIw+xecEf12dEN5WCft58ZDnp3lvQE3Xx+W1TdaJKmoN55cq554lBY5wUEEB6iyJM1enqgihF/JUKSZLeIEEutx5BlHKWjzHkj/PkuvlcjBnIXqmHY5a5LX7H/+W1RjDRpJpZlg8xl82vQf9SGu979WNBGyrVyQsgJaKZuHUNpAfsPAUP9T6/a6TT+JhzVolt+aqFUXBvgMs4ceGn9a9czXUg2XwFqJfG6lEWgDwn8ZqMNo4pZBOl+MsiDqiAFVUP3EONsEWYHj5Q0YG7sjjHnEeL65MAYO9URghISXXe2owMSP6Iali/V8hRitY82OwxiVsDyUz7202Eqnsgwuz5IGMUjRrcIx7/1RvHzULruNXfPOnInvtQcZsNMhl7FPy/AyIybRcXr5Z6sK7q5jGYy+qBj5YM8CMlN/oNb7dn6Qo+xI7RI+SM5SfMqlHjOD3v5cn26H613RkBX6Ry2nb2PFLMHXHkXtwEkhIJnJWNilBYZvhUT+i8eM8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR09MB6841BC6B826B47CA435289E0F3FC0SA0PR09MB6841namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR09MB6841.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8087e4db-ffe7-41c6-4c34-08d88fa4212c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 11:37:16.5749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6HwZYqZ1aKjwPvcrYTWNrZlyf2exBsQ22hVsMi86zcKZ6ZBIcafOaqFaWowCOiKH X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR09MB6602 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 11:37:21 -0000 --_000_SA0PR09MB6841BC6B826B47CA435289E0F3FC0SA0PR09MB6841namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tim, I support adoption of the draft. Regards, Quynh. ________________________________ From: Spasm on behalf of Tim Hollebeek Sent: Friday, November 20, 2020 3:00 PM To: LAMPS Subject: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg We talked about Russ=92s other draft earlier this week that adds more appro= priate modern algorithm choices for password-based MACs in the Certificate = Request Message Format (RFC 4211). The draft is here: https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.txt= Please indicate by December 9th whether you support adoption of draft-housl= ey-lamps-crmf-update-algs by the LAMPS WG. -Tim --_000_SA0PR09MB6841BC6B826B47CA435289E0F3FC0SA0PR09MB6841namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Tim,

I support adoption of the draft.

Regards,
Quynh. 
From: Spasm <spasm-bounc= es@ietf.org> on behalf of Tim Hollebeek <tim.hollebeek=3D40digicert.c= om@dmarc.ietf.org>
Sent: Friday, November 20, 2020 3:00 PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] Call for adoption of draft-housley-lamps-crmf-updat= e-alg
 
 --_000_SA0PR09MB6841BC6B826B47CA435289E0F3FC0SA0PR09MB6841namp_-- From nobody Mon Nov 23 03:47:53 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A23A0957 for ; Mon, 23 Nov 2020 03:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 IQcy7F5xFSR0 for ; Mon, 23 Nov 2020 03:47:49 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00084.outbound.protection.outlook.com [40.107.0.84]) (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 E87303A0954 for ; Mon, 23 Nov 2020 03:47:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c9551Qa9RSfZHtmv/bIU/sfyCR+qiouO6CmWZ/U694OIsWJin8t9pCmlzyqbdbhWz8h/2CSVzn3WA7qUWKECmlLI528spjyg398dPkDOrqlBB/lLSfqWSedBUdQgFouM/ZnLff0rYzdyFc2VlmnWy8R492dj+kr74Y8l84/NKi5qvrWVDxhoZSZw86AxV0Axzc07gSz7chuiPDSM6t8WnkuQflb7rLGGEOEpFLaza+Y6j1Nv/kmTp9UlYRysfSP+MF83+mXD8MKOObCmVdpBpufXbibdy6pnyyfupwrNztHs2z+k05Ur6nDvIXLKxCw7d8m9WaHf2SQHU1YLKdPvbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tZrR7ScuNAVcyf7HFWmiOAtdrgdB2jSE/UBhrFPgLCM=; b=dqc46A1vBtnw/v1XrWUFjlSbButvtTmcgiA/7rWy1MxJBEuvx1wXpGNbEPabC46IAqBV4ZYW+HT7eS0Fg7A+sDvqlSiK9ChJ6zAgEAugErgOulGE/xXhDc9kARE4SgItTMkgrPm9z0o6st9cOFI44MTWE1I6RYMZuoZHJc4EW7vljK03eHQRouabCRi5CcLmmtV2M5alX4SgxITCV4VMc5E4ocmoqlMFLqBz82xYnP2Ndfq8dYixu2t1c/cpvLANUs9sPtxG9sdTVmibkZhD4F3x1pbnKf/DdegC63Ioq9XP7i7KHt5IcFJGKBscF7N34p8BflqgDuq6cvZRZoyAGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tZrR7ScuNAVcyf7HFWmiOAtdrgdB2jSE/UBhrFPgLCM=; b=ZjBH6bQdTeHmgQcBbZB+4kQdJhY8J3h3EGM3v+YarudH2JydoRsSm03HmZkPzQv9aS21n4qfZqaEvJB2c50m6bVj3jzLzxNR8dkJ73bTal8BHtvmp8P9fhNM6hXaREOCkYi0kOOGr4xy8ZDCeACsiQhRYknWffadzUyTUkCRIcY= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB2836.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:132::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Mon, 23 Nov 2020 11:47:46 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.036; Mon, 23 Nov 2020 11:47:46 +0000 From: "Brockhaus, Hendrik" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwIT1DWrAABwkZA= Date: Mon, 23 Nov 2020 11:47:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-23T11:47:45Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=33a20342-f6cb-4c4b-8188-407673743fad; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.171] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 70057ce4-e6c0-4e92-6789-08d88fa598b7 x-ms-traffictypediagnostic: AM0PR10MB2836: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d+n37fVnMceSsWqlutVN3zJ0/vSnKBodzPiVXvBAo9QGjNy2FSIUIrplie4xWoqhLlXvEoFPRPaJxt7KjCcm4RsuXGaahJEGw7zDLzpJG4vCbHD4FxY/pOwjG757sTU+DVBl26S32WiUc395bJAA7ogcQagO9KRtgWo3rJBBZQP8QAuOxyjyiAOWySFEzDkxu/y4Pnj1HdVmaU2rDs+n2yY1EkVSU3JE9GyZmIqghewUZJ7jzWM/QBfdAbDmyvagNPvJ+sLYt/OWGN/Whbkh9TNyDW9Mhq0s/+0VQW3oAnbRvl7rBE9wY5i5oQTuVZvPwdHKYBU1gEIZ/QcXlVgRTWZpwv5cmixlOAgJswHcJeR6HYsutyJab4vb76lHITYT8+HCsdeMJO3ACTy7gJ6MGA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(396003)(136003)(39860400002)(346002)(55236004)(6506007)(52536014)(5660300002)(4744005)(9686003)(55016002)(66946007)(966005)(53546011)(76116006)(66476007)(66556008)(64756008)(66446008)(2906002)(186003)(7696005)(8676002)(166002)(8936002)(110136005)(26005)(71200400001)(86362001)(316002)(33656002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Ct6+ioWN8suEpTci03sf20z0dhX4NYsi/kUMp3mJmJ249O+xNH9LNCaLAbZ22O+41iWhcl9Cnp8yabrkOfkB0KvBlG9BA0fCERMMBVHYtwJIshbtmxFnk1KybmpSYg25eXWMCVMPLlEzCKfZR8l880LZ7VpHmN0Bj7FiPIbPGubs620w13Z7GqFjpMZ3RPBt7AAJUP49vWydTP7PyS3WJ+MO+jCC8rGQnyWznEQUysxGZtFnXQJnGL9vu6FMtND1uKtdLFStp4ZuxucpCdXa2QlXpgSX7FpPMRSrmb4+dPvrKqY8IOUZgGdniWdDMGZfL9p7DrygMyYJfc6+z51W6DFAXALdWIoIW1FsJZDq7cNP1EF+3dgKDUQeXGrb6e4+IsF8jjhx1JjgwgJcLW8PrqG/Gw6Mhoh5TctNeOVr0zfq7r1/I2TlRlBVmoVlmR6Nl0FaUJgKeJVQCGTGplxjQAtBo5rv1XzFf4t3HROCd891sDUpLnGFiYTNqRzfsv2hR8YLrMp05l9TGEJnp8qTk5s1XNebkP3iw+xkvjokMAsRj2KXt9MDY1YWpnIV4DjY6+LCAFf+0swj28OKt90mAZ6Sg4IWvzglyBVWIgskbJ8FiP4y/eHCtuRI7viL8EN5y1260bLgNgFimVP5tyRorg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24185D7167413C14A8D3363AFEFC0AM0PR10MB2418EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 70057ce4-e6c0-4e92-6789-08d88fa598b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 11:47:46.5828 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lHVoclyl6LGIBcUj7paQBeGEcdFDkosVedifqpqYEv0IXlTAWr3XrWV/kjcEGehTA7An0pXDVqfOtXH41XHtOKK455/NGX0EO7qjGFNeOQY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2836 Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 11:47:51 -0000 --_000_AM0PR10MB24185D7167413C14A8D3363AFEFC0AM0PR10MB2418EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption of this draft Hendrik ________________________________ From: Spasm > on beha= lf of Tim Hollebeek > Sent: Thursday, November 12, 2020 4:51 PM To: LAMPS > Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg For those of you who are following the discussion, you're probably aware of= the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use withi= n CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt<= https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-housley-lamps-cms-aes-mac-alg-00.txt&data=3D04= %7C01%7Chendrik.brockhaus%40siemens.com%7C855327bb23cd4370aff208d88fa3ddd4%= 7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637417281244470187%7CUnknown%7= CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn= 0%3D%7C1000&sdata=3D7krBt6ITJbtRtfVEhPlHjrDz16xepHFcy2LgqQq5n4I%3D&reserved= =3D0> Please indicate by November 25th whether you support adoption of draft-hous= ley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim --_000_AM0PR10MB24185D7167413C14A8D3363AFEFC0AM0PR10MB2418EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption of this draft

Hendrik

 

From: Spasm <spasm-bounces@ietf.org> on behalf of Tim Hollebeek <tim.hollebeek=3D40digi= cert.com@dmarc.ietf.org>
Sent: Thursday, November 12, 2020 4:51 PM
To: LAMPS <spasm@ietf.org&g= t;
Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-ma= c-alg

 

For those of you who are follo= wing the discussion, you’re probably aware of the following brief dra= ft that is related to the CMP work.

It allocates an OID for AES-GM= AC, and contains provisions for its use within CMS.  The draft is avai= lable here:

 

h= ttps://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt

 

Please indicate by November 25= th whether you support adoption of draft-housley-lamps-cms-aes-m= ac-alg by the LAMPS WG.

 

-Tim

 

--_000_AM0PR10MB24185D7167413C14A8D3363AFEFC0AM0PR10MB2418EURP_-- From nobody Mon Nov 23 07:20:44 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C0D3A03AA for ; Mon, 23 Nov 2020 07:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IQdXb0aa; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=qWbYJ1zq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4heEPHwPtJ_A for ; Mon, 23 Nov 2020 07:20:41 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46ECF3A0365 for ; Mon, 23 Nov 2020 07:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10104; q=dns/txt; s=iport; t=1606144841; x=1607354441; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PU/bdrVMEvpBwiWzB0MkUWVniFPL1slUWJF0DY+hKh8=; b=IQdXb0aavy3kEkv1XyjacwEuccxXYMHzkfMIlhsuLkMrXsIOyjzUO9D7 FpDkavTXDKiBieMkxFrjWNsSr4ReXU7uFppGW+Hc47vIkk6KPxT+cyUvv SWVCEBU9xYyx7Rd/0N3O15Zd4cVdsJAxI/qFIKrrY5HZJIVdsxh3xamV+ U=; X-Files: smime.p7s : 4024 X-IPAS-Result: =?us-ascii?q?A0DiCABH0btffYcNJK1iHgEBCxIMQIJyL1F7LC0vLgqHf?= =?us-ascii?q?AONWYdpjCuEcIJTA1QEBwEBAQoDAQElCAIEAQGESgKCKwIlOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQMSCxATAQE4DwIBCAQNBAEBLwIwH?= =?us-ascii?q?QgBAQQBEggGFIMFgX5XAx8PAQ6jPAKBPIhodIE0gwQBAQWFJhiCCQcDBoE4g?= =?us-ascii?q?VOBIIpNG4FBP4ERQ4JPPoJdAoFhK4MdgiycU4pTkSQKgm6EVIJllAeDGooZl?= =?us-ascii?q?FKTXKBgAgQCBAUCDgEBBYFrIYFZcBWDJFAXAg2OHwwXg06FFIVEdAI1AgYKA?= =?us-ascii?q?QEDCXyMOwGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AQ3nHohLbeerY90NNh9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv6k/gFrAR46d6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsuta1jbuHb07DMOFF?= =?us-ascii?q?P4LwUmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,363,1599523200"; d="p7s'?scan'208,217";a="634840841" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Nov 2020 15:20:40 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ANFKd3k003587 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Nov 2020 15:20:40 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 09:20:39 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 09:20:39 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 23 Nov 2020 09:20:39 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mePy1qvMJF/SIfgxpeM0dl+yfhWuvQB/aFghahR/EWr4hICfAUmF28HPlMf71V0OA52NV0+sLY2zFSZpzDJKZspZkMQ2ssHR3vWsHb2Buhb0QnwbkVzZpG2k1kYmnU4SgNSL5VIkUtojnIO5MEKHXfRDiJSpJpzrvNxT83M0RyhQBjQfRz5OVdF4L/cekvylGeqkycFpDLIe6GwE6KjAxT+GHa6oc9PD0xHiHRXo7UtHNBV9dRyXxyjS9m+WLMzujvT47h73Q2wLBfrIek2o/Nr5IE3vJbdGZwgIYb9ZkOWITBoHSdrZbLvRMA0RhXJvAz/shuRsyJwBTnUwI7L9Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hyMllsDap/pbG9KRrbdF7VrHOqTpBXsx8R+kz/scDis=; b=knCsHhwQXU65zpQQs8+3vRgF15KRaN7jp9zvfhGY+SLcwGh2ygNWJHWNnA8q7HhKwlQ4S5nw8CvTr8dHwAzhbkvSwVou9E/DXP++aFUP7fz6JV1le8AcsDUbIGi7fcfIB8plFPxqEQlgWJR6yGT3tjjx3pkSOBgz1tvtzyeLWe7pDOt1eToWsUQEqcggEGdbkAQtoj/UKqe89FxdEn4rFe3tVffmIfLulENpsdAbtn6o9BAT33wOrFaKXh56rcY+hF+/5VipvuVmsDUFTpnbZA2Pswk+3n4Y8cqEmMB5halO3Q+y+L+0l52w148j/Epx52TqCG1KacDNgGc6Eb0PWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hyMllsDap/pbG9KRrbdF7VrHOqTpBXsx8R+kz/scDis=; b=qWbYJ1zqddXVrEZn9LIaBT4YAaxORmKXUqqPv69szhoQA/fZC1czV+bnJgNYoqZ15Y3G+rICK6+A0Z74N5PZI9G9osxYqvkuU70RmzPhi5nWTW4Amfg8Lhcx4ctKWP9r16Y8jcRFWf4kccv7WAxK/HNF9ggWB05D654rxD3+YDc= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR11MB1523.namprd11.prod.outlook.com (2603:10b6:405:10::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Mon, 23 Nov 2020 15:20:37 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::1dc1:e7f4:84ef:3711%6]) with mapi id 15.20.3589.021; Mon, 23 Nov 2020 15:20:37 +0000 From: "Panos Kampanakis (pkampana)" To: Tim Hollebeek , LAMPS Thread-Topic: Call for adoption of draft-housley-lamps-cms-aes-mac-alg Thread-Index: Ada5PUeDTi8Ao42uSE2MX/yt85ISNwIbtuRA Date: Mon, 23 Nov 2020 15:20:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e78e15ff-434f-45c9-00ef-08d88fc354d6 x-ms-traffictypediagnostic: BN6PR11MB1523: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bOybJSmhP4s+yJ83YZH9HsqOJos3FncX8/ywPf0vpJC5bdMx6sP2sDdq2Yg3C/9dcJeHsNo4kd9KvPwjUmeIn8ID1wrHMGv8ylEtvPElubV1XCNwM/TZ+nwrezt/wPfcLgs7b7zgX2MAbV1YcfBUwf+0pYyEidM+H/jYX/QiWaM1KtdQmA167hvJ8f+rJy5MMnMlD94uanD9u4Ij8gcyczXsu2BqnBwt/FCkyxo0Mcmub5DMxmIbOWiNEsAjgf+SIgm23c47/Ce72Ig1FbU+sYAjjuMu75uVRU2mxkepD8XTv1lUpsRRBt260lBTzSsENbdtPXoyQOa6qxT9tCgOd8XQNMz0/VXYwchS5sVgPOwHCMgQdoC9wiMblQAYKfEsS1CZROxW+elsKguN3ZbK2Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(376002)(366004)(39860400002)(8936002)(5660300002)(33656002)(110136005)(4744005)(316002)(7696005)(186003)(26005)(53546011)(6506007)(66446008)(64756008)(52536014)(66556008)(71200400001)(66616009)(66946007)(66476007)(2906002)(478600001)(99936003)(966005)(166002)(76116006)(86362001)(9686003)(55016002)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PiJ/yfedLJrD20jOSMF3qhx7RlyfLSp488frFhILjh6JcYSxjEuKK+nCxgD4J8SnBpO+1KU3yH8MUBRmodPN4a5VueG9fgfqOBQYrib8RRU3oqW+BNKJNfl6f20dvDKkzRHnFjbi4ZrY7TAwHUeCpaBr9Q0guxW445JQLTW/9hazxga97gCkBJ3FRw24VCfUzXtgaeKz2awzEBECTqFSqK1qevcVoygNAy83CIVvqjadtaVizIXh3kZ5zMqZ6SpcJIoRGABswMDxYqE9h4AH7yB0VWW2DLfnThKv1jzHHxZnxw8XI87oA1dPTTD0wnpzmHlLxoxHsEHg/zhTe5iYbIJcmEMNKtHOYjgai0wg9Fv7XuCJg0ywyyqMqhhcB/+Zqk0GLb1C7Hy+122TN2T3HiBjhfdxzQkKVT1v+8yXVFUkpZZ1mbo3BQ+qkWHlF6BUWqJ5mW3mTRUjsqLlojql66rGzJvZngfJ8uZSCiDEn56CncKn4ICHOWRJfUq2AeVJaDOJuocmr7gRGpVd3i430G3hxTF9CyhI7a1drfqAvXyAsIt9yVYIfyVq2/KQurrGkvZgtWifCN1iRhnKVh68DdBEVvKxcNFEx/E3wxyZ9Sdw/kwcjllS7T0+RtPmgLi+FJ+BsANI/ApgANyI9hH1/03OE4Eov5S/0/3vsIcDJ1reXNyWRa8PKSiXanNDyxMWnBUH6+IUOrfR3ZXXGChYPU81Bg9BQpQIJCJyr7vK+osIhLAaATsiuwesUzaDa+FndbRP1b6MXFVoehhp4d6oiPtNm2NOXAxcG/YCRnBx/SpADpeBlcU8BF96k0C2G3HfKITGBZATIVD7AE9CoDr/UUxvKPNsoSJvzrF8546HdfZSlR858PwVq/CTW38Iwa3eUjmoJtDz/jyCZfI02suFqQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0008_01D6C182.482E9550" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e78e15ff-434f-45c9-00ef-08d88fc354d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 15:20:37.6771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ob4z98NflTJzyWrb9PAaNjKziLcnYSUZ8RL4mD320cqKMU4aXJuN7EpBlHA9Tqf09QXGkhovXio+gC6IREUc3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1523 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 15:20:43 -0000 ------=_NextPart_000_0008_01D6C182.482E9550 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01D6C182.482E9550" ------=_NextPart_001_0009_01D6C182.482E9550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support adoption. From: Spasm On Behalf Of Tim Hollebeek Sent: Thursday, November 12, 2020 4:51 PM To: LAMPS Subject: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg For those of you who are following the discussion, you're probably aware of the following brief draft that is related to the CMP work. It allocates an OID for AES-GMAC, and contains provisions for its use within CMS. The draft is available here: https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt Please indicate by November 25th whether you support adoption of draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. -Tim ------=_NextPart_001_0009_01D6C182.482E9550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support adoption. =

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Thursday, November 12, 2020 4:51 = PM
To: LAMPS <spasm@ietf.org>
Subject: [lamps] = Call for adoption of = draft-housley-lamps-cms-aes-mac-alg

 

For those of = you who are following the discussion, you’re probably aware of the = following brief draft that is related to the CMP work.

It allocates an OID for AES-GMAC, and contains = provisions for its use within CMS.  The draft is available = here:

 

https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-ma= c-alg-00.txt

 

Please = indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG.

 

-Tim

 

------=_NextPart_001_0009_01D6C182.482E9550-- ------=_NextPart_000_0008_01D6C182.482E9550 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAxMTIzMTUyMDM1WjAvBgkqhkiG9w0BCQQxIgQgNi70WsqlWC/iFsQjMsfL1CuqXl+BJtN0 kTTUVWXPkrEwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA efD9cNPuugVqpFctjxxvhpV06xRXkLkBhMWdMo1aspreLxFvzZP6JQRJWk1oCQufvQSlFIOkwEPr YXypEoZ+y4MsyR8xvMeoRi6xa4I2B1Jc9KKCP1f9yuDqwEJtYB0aCik7k6scs9HkuO4XpjUa45aC t/pf7df0Vln57XNKqlAp7km5pGmuGmgLhTAV5P1voojCoIr+PYxnLCiVVoubUIIwMikSVjsA00pZ VoCyHxLA8NymSGlECuiQmNhI6DeqD7rS7FYCBA6yuetnrpEc2+ni6EdI5xWgknSK8+vraCkiUrcU 20V1Q0ubOK1JMXFQq6qMoOiSTE9pWNKolBcUpgAAAAAAAA== ------=_NextPart_000_0008_01D6C182.482E9550-- From nobody Mon Nov 23 07:37:30 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5E33A0603 for ; Mon, 23 Nov 2020 07:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZTj_B1ROeat for ; Mon, 23 Nov 2020 07:37:25 -0800 (PST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 AD10E3A074B for ; Mon, 23 Nov 2020 07:37:25 -0800 (PST) Received: by mail-qv1-xf29.google.com with SMTP id x13so8957022qvk.8 for ; Mon, 23 Nov 2020 07:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWdGg59KLbzcTsbO4JVkU0cS+SvAbSvkgXvTVOv0s1U=; b=X5mKkA/f24L+AWP0b7AEpK/GfRl+VgjMVoS81RcNk6p3oW3ULhu7mdbYst/C8o71Fd 6G+KVRydoBynjl0Jt2yican8lwu5Ioe2zMvjV+M4uH/XcYNU8Y85LRTgohID/xP55IqO U4cc1Te++m6xDj2cJUkIzrNqKWNdtDquAXY10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RWdGg59KLbzcTsbO4JVkU0cS+SvAbSvkgXvTVOv0s1U=; b=YoioBG6qn04kGw8hm7WpVHX03fUeT/OAS3hOUv2Zhu17Bxhjdzd8JPxYRP0K34dLJk 9nIpvE2vbqpIH2DjEGjsteuPzM0AKbmJK+okHL0WeWwsTj5iJa8f6qglKzNvOiAV6pzy tE9+YHVnuA3yBvZP3YPEJ81uRRuD90Yk9/aQsrwOaOLP8NJTLUezv8JcD0f1ClBKREPc yfnSNi6Mrx28e76LenXwKzYV9TwoyvdaFnIIxyiSVQ5SUClDU5HDnFolCuhks9BJ417W 7AlvXiQhfhhmS5WSMrZhaq5r/4w+xmjYr0LE6pInZvmbMRfLKBUyGmBVAd6G1Tex+OdP ZKZA== X-Gm-Message-State: AOAM533xQshDtG3eRHu7KmiSALoCJNxL14feWTj2G90wHY1qmfO6q0cp urV+jn9jr7x3EU9pUjFkXULtnqBbH5uD4g== X-Google-Smtp-Source: ABdhPJw1JVo9ENYlJq7a6JGYqObYi4lquguKHZNPjtM09kTotdhH4bxr2w1jdxO/CPq14vklvyUszQ== X-Received: by 2002:ad4:524b:: with SMTP id s11mr30613734qvq.3.1606145844411; Mon, 23 Nov 2020 07:37:24 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id r62sm9753439qkd.80.2020.11.23.07.37.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Nov 2020 07:37:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: Date: Mon, 23 Nov 2020 10:37:21 -0500 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <39530D49-453C-48F0-B573-AEAA73AB6BA3@sn3rd.com> References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 15:37:29 -0000 I support adoption and am willing to review. spt > On Nov 20, 2020, at 15:00, Tim Hollebeek = wrote: >=20 > We talked about Russ=E2=80=99s other draft earlier this week that adds = more appropriate modern algorithm choices for password-based MACs in the = Certificate Request Message Format (RFC 4211). The draft is here: > =20 > = https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-01.tx= t > =20 > Please indicate by December 9th whether you support adoption of = draft-housley-lamps-crmf-update-algs by the LAMPS WG. > =20 > -Tim > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 23 09:36:51 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC23A097F for ; Mon, 23 Nov 2020 09:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 xFtHmYXiJN4I for ; Mon, 23 Nov 2020 09:36:47 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70074.outbound.protection.outlook.com [40.107.7.74]) (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 942863A08BD for ; Mon, 23 Nov 2020 09:36:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XU5rdl0RLepzxPZ1bmsgwTMZvB6jslE6bReb6bk5Mpyq7Jd1yAYmj5HjtgkBHDhGg/jA1E7LHZuLirnZUvvouuIJnW5XkaM9dmlt1J3mlSWsKHBbK4f3fcr0Umbzd0z7YJaHVRrWmuO4/XCEszJB9PWeiJzVildBrIY++FBP7A5BvJpPkHb4qcDs6E7gre82Auxwg7tu91ZJlyicTZs3Z3ZMHZ2GEP/pKHC67tIA4M5PKKD3R81gNqHulliL23/r4n/7tmFHiM8U+vpSaBlrzBV0/LBw4nLrA3NvTJbFK9m+eIIQij9NHjFLKi2r20S89Aakp1b1APIA4MkRdnSsXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UDaO+p2VOqvVsGOr0vLcDWoDPfYjErrx+XAdZ5hhIb0=; b=j4R+vRvAl/q4rqnK1NIxTYzVp823Ql6VrZUB/u791fRLDhK/YWqUAT/9AyfusRMKfoT+8kww934TleOE7eLe9PBXqXkDDdZ+WMfdCNrCKmbzFsuvMxTT7rcXDpqL3/YIl4cejLgejGjkYdhMa2I/dTt1hKVPLJM24jT9X8qwXyMKUIl6+jlnj5SGmd17ikFUgzDia2ttFlOmdZ0h88sg0K1hW7k1mxLdu+3ZQaLG/F45mbnymmhnRVbSQ25HmKG4gERR8UWeNARhD3r5Ew/kNPLf2fVSHsu15Ocu5gPfFgAwEIGIVqn4C2XMvL1+MqvTYIjLTDpZYuugVx/GtRS5Dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UDaO+p2VOqvVsGOr0vLcDWoDPfYjErrx+XAdZ5hhIb0=; b=I9veqrrNlF99N5E6y3WvxVfr0UBwOcwSwsCtwkWJTYCerEgzzh2XOu4F4T4bYkWyK99HyLvzWJ+0AiEnZU2oJVC9UGo2DYY+FRTabPjLCcrtz+TFRmyhmEVH8qkgHgFZzPeEEJPIEawjJjv5x57YSjILplrBg8sb2IrGYHS+IDo= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4118.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1ff::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Mon, 23 Nov 2020 17:36:44 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.036; Mon, 23 Nov 2020 17:36:44 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS , "hans.aschauer@siemens.com" Thread-Topic: draft-housley-lamps-cms-aes-mac-alg-00 Section 7 Thread-Index: AdbBvjej4BNYERxwTuOWlofLGGAE3A== Date: Mon, 23 Nov 2020 17:36:43 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-23T17:36:42Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=64464479-1a37-493c-85f3-7a27fb8885b4; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.171] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b56668ac-f492-4eba-fb6e-08d88fd65854 x-ms-traffictypediagnostic: AM9PR10MB4118: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J41Sep/b0/i+w9n8ydrmOoYrJBE3UrKCmMVdtzzDdXhZkNNKpySVE+358f7ltgPfqjcee7zsYhwN+3rIhLW6t9Csstz2VGnGVfleFQ3U8qLkQYqMvqz3WpjggseILcFhPqk7KF1/EPI8Wx+yMpfvAM7pV81z5OCpUfQfHb+Q2RoXdTIJHAXAzDUsZpMlBqyTxI36Ak5/akdj5nE6Q7qSwf7PfWRO6EDnFPuj9CAq91+xVvqCkExPCDZLcYU2+mZDVe+/UXUCqMQ30wdlo009THUsX8gGENhlzaqL8bGQ0H2iKdaL5qFZHMuO2jWEKZdmgv/B+cx33uEbW64PPnldxm8zsDP6SPRN5+ph3Zf4lg/++fe47G5afF6UkapXy0luGzhttgDwu38KV1+/735OwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(366004)(396003)(39860400002)(136003)(55016002)(8676002)(186003)(316002)(76116006)(83380400001)(6916009)(26005)(54906003)(7696005)(2906002)(9686003)(15974865002)(71200400001)(5660300002)(107886003)(66946007)(52536014)(86362001)(66476007)(4326008)(478600001)(6506007)(33656002)(8936002)(55236004)(66446008)(66556008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: oScH/T9F6g/LEPNyBSWGFWAgAJiaMrc+AOZw10BWp56t/DneCIsId5TmO0y8CtsgD4dJgxkjuY9B/RYfWwxB83YtHjJ5sglFFwOylzivNf+GlT+1yh6CFxOtFIn/c1v0U6qhGOuRSjILgX99nw6kPmS3Pz1q6bEbq+t3+7QVUMGVGjXN+UnDojz0X8DguNzcXxaM5XSuvGGtRkwPSIsJpkSBDKjBP7ZygjIX50A/7kBrQSmFqYDM/WEH4I7JH7/YUbRIUv7MpEinHEiNgeoxshy5QAm2zEwMBuH+/mIzoYJl9R337BDpXI4YtWZeJj1g7P6ZbkufcGfir4tzVU/oNAXqKxzDC5jUdfFn0abVgvQN1L2FyhcW7yeupjEMDIaOhSp3zAZgUE58+01VjuSqZdd7H6qoXvaHdzMWm96KduhQW1FlYCU6NnAM0dbga2KWB/DtTKbFZTZfKo1eDIy38ZI8ifW3HCYBV12jxdOKtMhETLkae/ShcMA41CjuOwzYb76nGIoGacjaV5PvLx+DZ/b6STjcgySxtQD9g78bBvE+x6TmYD4vsqf8Z5XIpGOuhuA2nR5yrPNXoqoPB537l4nDBuBFfdL11soe6yemtQ4ujbLO0Sc9fdylFqDqGR06IKzGT+RGWETH3oqYrDMKBZDbtC2cpZz5NFBQpYDGrtmUH6KMWzJsMoFRNlik++Pu6ZTNip1MeR2blJFJG1k22V95H8N+1H+sjEGT/qACIz/axad0oFW/4WxIuSkz7yCTLEOXlsCTJPUDY/JEuD9VeftksjwbAjJ327kM0N/1A41n67UV56EjL7vCcWYldDk6MtewIb68BW0NqRbZ//HRtaBaoL6qXjwhxS8DIhmFy5NSMEvtYoWGghazIa76O7YobdiXp6MpiSjzkM6siTk9YA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b56668ac-f492-4eba-fb6e-08d88fd65854 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 17:36:43.9553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0RG6+OMrlRGne+hvwoSoDpS5OXne71W3PDJvu4mcLXAE1ytlDgVscEudAQG4wA095xl/2IozhpwQdF6x2plGOT4NTSrxa/MX2tsnwQVNsLY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4118 Archived-At: Subject: [lamps] draft-housley-lamps-cms-aes-mac-alg-00 Section 7 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 17:36:48 -0000 Hi Russ As in AES-GMAC the uniqueness of the nonce is crucial, I want to propose t= o add the following text in Section 7 right before the last paragraph. "Implementations must generate nonce values which must be unique for a give= n message-authentication key. Repeating a nonce value only once allows an a= ttacker to generate valid AES-GMAC authentication codes for arbitrary messa= ges, which results in no security of the authentication code (see [GCM], Ap= pendix A)." May be it is also of value to add this in Section 5 of draft-housley-lamps-= crmf-update-algs as well. Hendrik Hendrik Brockhaus Siemens AG T RDA CST SEA-DE mailto:hendrik.brockhaus@siemens.com www.siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann= Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive= Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Matthias Rebellius, R= alf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany= ; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684= ; WEEE-Reg.-No. DE 23691322 From nobody Mon Nov 23 10:02:21 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41D53A0BEF for ; Mon, 23 Nov 2020 10:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZTM4GdVeHzn for ; Mon, 23 Nov 2020 10:02:18 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136CC3A0BE7 for ; Mon, 23 Nov 2020 10:02:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9ABA5300AA4 for ; Mon, 23 Nov 2020 13:02:15 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DsjTyMKKvcWy for ; Mon, 23 Nov 2020 13:02:14 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 04E25300A4B; Mon, 23 Nov 2020 13:02:13 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Mon, 23 Nov 2020 13:02:15 -0500 Cc: LAMPS , "hans.aschauer@siemens.com" Content-Transfer-Encoding: quoted-printable Message-Id: <22D76412-D502-45B4-80E3-6DC80449C6A8@vigilsec.com> References: To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] draft-housley-lamps-cms-aes-mac-alg-00 Section 7 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:02:20 -0000 Section 3.1 says: Within the scope of any content-authentication key, = the nonce value MUST be unique. I agree that the Security Considerations should also talk about the = consequences of reusing a nonce value. Russ > On Nov 23, 2020, at 12:36 PM, Brockhaus, Hendrik = wrote: >=20 > Hi Russ >=20 > As in AES-GMAC the uniqueness of the nonce is crucial, I want to = propose to add the following text in Section 7 right before the last = paragraph. > "Implementations must generate nonce values which must be unique for a = given message-authentication key. Repeating a nonce value only once = allows an attacker to generate valid AES-GMAC authentication codes for = arbitrary messages, which results in no security of the authentication = code (see [GCM], Appendix A)." >=20 > May be it is also of value to add this in Section 5 of = draft-housley-lamps-crmf-update-algs as well. >=20 > Hendrik >=20 >=20 > Hendrik Brockhaus > Siemens AG > T RDA CST SEA-DE > mailto:hendrik.brockhaus@siemens.com >=20 > www.siemens.com >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim = Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and = Chief Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, = Matthias Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: = Berlin and Munich, Germany; Commercial registries: = Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE = 23691322 From nobody Mon Nov 23 10:49:57 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39513A0C27 for ; Mon, 23 Nov 2020 10:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFbi00Q3mak9 for ; Mon, 23 Nov 2020 10:49:54 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 666553A0C02 for ; Mon, 23 Nov 2020 10:49:54 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id y18so1634406qki.11 for ; Mon, 23 Nov 2020 10:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbBNpOAnaip0s3iD4kMxuE5uOCIBGt0tMMf2Yf2Of1c=; b=bsFm/wQGnPOsdBbMKsKvndGpQV4gSV+uZgCxmr0Mo921xBLGPxYSAgXZEIPPMiIvLF Jr9Gpck7xSkBlwXHdbRaBQ0p0S5evrToBTjuNe+Q9ytLt3BGnyUy3MSg0MAA8CWVMI6o c+EIfM1es2pB1HXBzP/Z7up3jSId397Ja2SFA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbBNpOAnaip0s3iD4kMxuE5uOCIBGt0tMMf2Yf2Of1c=; b=rw9dP+t3E+/5tTrVpJX0z8EPu3RIZihqiKizrETPVo81Bl7iQddaEZSccGts0LsT9W 2QtO7H09pClXjUA0tU/9y4XibQw1BrjBCiiq9g/X6cbx7Lgn0NpPktg8CiRGxZ8GaSGP uVbCYEPctISpTOFbZ9bDhDTqoeod5+vC20GP1gr6KxdagEDyDkLg6la3FnFSd9YDXuMG bko7rFj5hg+vs0ClJjSpvwgQvI20QbCqdPuQapInCx/abKbNC/im9qvmKB9GvWSPdRrG FoA+omjpz2fDmFn4XS+GXtg1vzm6j6eNlyfkhPAoM5NktW6LfXd0gvQ0WElqhyv3FBv2 8XDw== X-Gm-Message-State: AOAM533xwCtpj80fjpzRuFB3daD1HOwPa68UwgXpagGqf8JSE9/9uiPW cQe3QGRla0AdlMhhmc2IBcesBiR1uExKaQ== X-Google-Smtp-Source: ABdhPJyoAjtQ0bJwtvqT5MVs8/det85QXkUh8CQZ9tEJvK8X+OCFIM7E8f57SmPOd1muM7JjqsWeJw== X-Received: by 2002:a05:620a:12eb:: with SMTP id f11mr864386qkl.371.1606157393357; Mon, 23 Nov 2020 10:49:53 -0800 (PST) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id u24sm10822999qtb.33.2020.11.23.10.49.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Nov 2020 10:49:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: Date: Mon, 23 Nov 2020 13:49:49 -0500 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <3B343403-F827-47CD-A951-4EC73952455A@sn3rd.com> References: To: Tim Hollebeek X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-cms-aes-mac-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 18:49:56 -0000 I support adoption and will review. spt > On Nov 12, 2020, at 16:51, Tim Hollebeek = wrote: >=20 > For those of you who are following the discussion, you=E2=80=99re = probably aware of the following brief draft that is related to the CMP = work. > It allocates an OID for AES-GMAC, and contains provisions for its use = within CMS. The draft is available here: > =20 > = https://www.ietf.org/archive/id/draft-housley-lamps-cms-aes-mac-alg-00.txt= > =20 > Please indicate by November 25th whether you support adoption of = draft-housley-lamps-cms-aes-mac-alg by the LAMPS WG. > =20 > -Tim > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Nov 23 23:12:38 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBBD3A164B for ; Mon, 23 Nov 2020 23:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 dwyp8uRGS4r0 for ; Mon, 23 Nov 2020 23:12:33 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70080.outbound.protection.outlook.com [40.107.7.80]) (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 B18823A164C for ; Mon, 23 Nov 2020 23:12:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lrvKVc3QBRe/TdQQJgbGIwyHKC3b48Uoh16aoOTBKa1+tmsw3U7gMGExqd9WpHQKuy8lbt1BUNCraSFYvkgE03twpLr2EO5HulhcOxpk3EjjT+P8Bw1+nYcR/VIP3KbfERTzhsuDd20or3x0k9z+yF4cDVJpv9mbPmVXRRNPRj1LFMjUMkvsyTxU2s8VXVzeWLiWddtcgnEHK5LFUYkypeTNGxKI/ULrNJlMupCbCEz7SfZQPsQ7Z0I62mZs8Fk71GFMDTxF2ZfXT8C5uazPKEj53jNWH8f9/r1LAG8084M2ArZ14/nFT2+KGJMo8KhFg8DbGEROUk3Hma+FCAnAxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rm/FZmYwPbl/RmSh35WLBAgr8YcXu4xEwQH0QqHZ14Q=; b=jU9BkU22gdEz7mTOH2rYTD/vsQAHeqzKCYpd9XfS4td1fdVlxMzsm18OpXRduujmQ0jJXrA1cXnED7l3tpwiwTL4wWEtxT1Mm47yXrpZT/LcQSkQD5NMuC5hiDldpB04b+MF5k0XL9Bqgti63v1fXBFLIsYEP5ttKRAKWG9YGviCmdoriWJMJHPEl4VXcC0RsIOWZ3WSwJXivI1+p2bmiHwVFuF31oPKJ0rpvDTPS6ar81KxnLKlDOQ2zUpzGbHtMuRCDkgx9hk/UyN18ADWYQ9ME6q5cvgN1x1somasLX8zsnL8qAGyLLxiufUPi66734CLXJZcYbBB2JfQYttWdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rm/FZmYwPbl/RmSh35WLBAgr8YcXu4xEwQH0QqHZ14Q=; b=fe9VkMFDMBIK4zR8MLhRib2xv0QfGSy28WnVs2fq9aJRdx3w02rBJEupqRaU3JBgqWc0boo9Uu8KhRmtMVY8VHk4UKDdLpIWPJQrN0I89qEO2pa8k0Li0hqBbTBlwqgDo4IlEkTaeqbqzZjpftol2KG7j0NUn4vGbFqcbzjlaMY= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3028.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:15b::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Tue, 24 Nov 2020 07:12:29 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.036; Tue, 24 Nov 2020 07:12:29 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS , "hans.aschauer@siemens.com" Thread-Topic: draft-housley-lamps-cms-aes-mac-alg-00 Section 7 Thread-Index: AdbBvjej4BNYERxwTuOWlofLGGAE3AABI6+AABuQDYA= Date: Tue, 24 Nov 2020 07:12:29 +0000 Message-ID: References: <22D76412-D502-45B4-80E3-6DC80449C6A8@vigilsec.com> In-Reply-To: <22D76412-D502-45B4-80E3-6DC80449C6A8@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-24T07:12:28Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=88cc81ec-ac70-43eb-b071-0559236eb7e0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [77.9.5.44] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8720fc2f-33d4-47d9-7d81-08d890484e49 x-ms-traffictypediagnostic: AM0PR10MB3028: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S3tqJjc6uorGxMPVpPEsgu7bBVmeNAyCBvyUY3AKzm7epfezgKbqfNBKZH1RGylfzeQQHeLmJX3nKbA6oKpZFBK2LhKjrTthdLmQPJxtCQAKE+I6a0USJ1lobRe8rIgxGnNZO7jJfP16oiAK1ngDJB0+28alhIZ/BgipzUpN68vSmOvFGI4XG/ZRKauBKblitfihX47YLamxCrrl8PSkgdSUMDIo1ICHokn1KyOyeqhtpNfFuaD7E4Uq0rBsryT7Hk28gk5uxV2vEPfpsYSUwmqNH01FQ6VPAiEN66CeMkIoyn7U637dsVkTbSsGQcEmGW7osxrPPdLae5z8OvyqCgFTeEbp3lwXTee+h3hAxr6jZ+v6/Z5yGHzDzp6+B2P9VxoLxRA7YfEiYZYeyMa66w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(346002)(39860400002)(376002)(76116006)(66946007)(64756008)(7696005)(478600001)(316002)(66556008)(54906003)(86362001)(66446008)(4326008)(6916009)(66476007)(8936002)(966005)(26005)(53546011)(6506007)(2906002)(186003)(5660300002)(52536014)(83380400001)(8676002)(9686003)(71200400001)(33656002)(55016002)(107886003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aMMcPNl1/8AT+LDEqg04lQXRcxt5fmk3VZvkWcfUNPPhFEDI2c3WspCZ5+Lo3KJ+l04r9+fnWak+Np3cH/1iCwdmoxKDBJkqelaZXCLfH2AFOzSC6Jrog1BJJwXiAW7YYIteyd+vZwblp4jT0hPoHO278R86YUuOUSENBM6262KayHOGqIGfkQyTLPL1JH5r19rP13+JvN0rJ4gQaa8yol5DcE2HdISaS09p5HRmlzMhspHkBoKYhBYAKKjetl4+UEZSADis19y8ap0q7bvlOThrU2RBpTRI5Cdb6yBcd5Fk+8m7jZK9xzz/+mARzacYtzGqUx6TirtnLj84f0vH0HJULfnHdfl4ltH6BeEg692chYu8lgFqzEDAn18kdin+JzqK4ip4JbS/Qja218WOQOcUlSfwuFFCJ2zq/dHmCB+cfcZFbZ/HoNM6gnv0GVAH7gXGCcSKDri0szxhW8T2dbyVho1bJwNrWvzT3DihyO/uFzBZNsOYo5S6iTZdlnIIshUGvBOunu+xuTDGIBniyKEU9/xMb/3Z/7xR1hz5Ik9WJ67s+EhwQjsr5sz4H92gd/upsqovcFqWcJsPpnttewhQijWgPaG3NiSAT4gXyjG4LW3EfkTnMDLvOhFok6HrMSESS7KFfIFnI8Qf6BTeHzlTZ1wKpiKxiRynzXIvY2R/MX1SbN7IH/L17UC7vtz8jXSomjr4LkP1hIHOTr79za0uMznixpk1V1uNuC3isSqVpqxOPrw10OKmiF813rJNTsJB8lxmAFfNdXBFXA4LCeMHTE+BwSGs1HKMJmpwnfTIK9uzsHy/zUL1XYzGqfXXE3/auNcwx8x9oa8eCBmal0qNBo2E3kBoNXL9f+bkOy52F4CC0eZAg63GkVFp9ug9iNf7R2lhT7B3JMNlNs5kGg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8720fc2f-33d4-47d9-7d81-08d890484e49 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 07:12:29.7419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wZPHHMtyYe2KrslVJWAHRHOlxjNdrP3++Zo1I8TIcIgfapJT7nekyJ/GOwEQkR7NRwtjclTkGMKLVieT93I5Xx/bdOiZKdWCzjsHUSubHDE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3028 Archived-At: Subject: Re: [lamps] draft-housley-lamps-cms-aes-mac-alg-00 Section 7 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2020 07:12:37 -0000 The goal was to make the consequences more explicit. Hendrik > Von: Russ Housley > Gesendet: Montag, 23. November 2020 19:02 >=20 > Section 3.1 says: Within the scope of any content-authentication key, the > nonce value MUST be unique. >=20 > I agree that the Security Considerations should also talk about the > consequences of reusing a nonce value. >=20 > Russ >=20 >=20 > > On Nov 23, 2020, at 12:36 PM, Brockhaus, Hendrik > wrote: > > > > Hi Russ > > > > As in AES-GMAC the uniqueness of the nonce is crucial, I want to propo= se > to add the following text in Section 7 right before the last paragraph. > > "Implementations must generate nonce values which must be unique for a > given message-authentication key. Repeating a nonce value only once allow= s > an attacker to generate valid AES-GMAC authentication codes for arbitrary > messages, which results in no security of the authentication code (see [G= CM], > Appendix A)." > > > > May be it is also of value to add this in Section 5 of draft-housley-la= mps- > crmf-update-algs as well. > > > > Hendrik > > > > > > Hendrik Brockhaus > > Siemens AG > > T RDA CST SEA-DE > > mailto:hendrik.brockhaus@siemens.com > > > > http://www.siemens.com/ > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief > Executive Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Matthias > Rebellius, Ralf P. Thomas, Judith Wiese; Registered offices: Berlin and M= unich, > Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, > HRB 6684; WEEE-Reg.-No. DE 23691322 From nobody Wed Nov 25 14:43:32 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50A3A1F5B for ; Wed, 25 Nov 2020 14:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8XCjSQlQV8O for ; Wed, 25 Nov 2020 14:43:21 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3084A3A1F47 for ; Wed, 25 Nov 2020 14:43:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 805E4300B2F for ; Wed, 25 Nov 2020 17:43:18 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AckXumrYfbWO for ; Wed, 25 Nov 2020 17:43:17 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 64C8B300A1D for ; Wed, 25 Nov 2020 17:43:17 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Message-Id: Date: Wed, 25 Nov 2020 17:43:18 -0500 To: LAMPS X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [lamps] LAMPS Minutes for IETF 109 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 22:43:30 -0000 https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00 Please send a note is you see anything that needs to be corrected. Thanks Jonathan. Your notes were excellent. Russ From nobody Thu Nov 26 08:32:46 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675A33A153F for ; Thu, 26 Nov 2020 08:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 KCiBKTI7C7fY for ; Thu, 26 Nov 2020 08:32:37 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50051.outbound.protection.outlook.com [40.107.5.51]) (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 743803A14A8 for ; Thu, 26 Nov 2020 08:32:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g/ARE4fQjrDhzOQ2GSWx/xqvS8dcVwkns4hRBCvRrTeotnwLmGm/o9MwUItxFUENQvJmzmtPRP3EOliBs/AvykSe+Vmjb5SWSCJile/fDj4bDR7PQB1MeADN+Xz+S7N/G+ejGA9lNx3vRNtjBIUR62fwji0twSGPn3O0MldgKxyv+zRPJ5lHnwnZwcEckUbKHD0DlES5C6AKlrtFEyNG70O9df0nL1HUa0eS7cl3BPBuNrJAM68fK512zN5Usg0xsT+QvTn0MBynP5tEwzYtL2s/HQp9p6BPw1WQg2N7PBO7c79zAWTVKxjmIaxJRHJhTPaAD1d4cFsYemPdwqvtNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DKWyoluHVpKcSepPU2BRhI4Koh17NOHqNmabhooA4bg=; b=Cz01R4FZ8Klz8UAk9Cgc7ECOhBgd1itx3AHm0pFXjoYFZIQBVPp1jQU1NBHkdUCeoxC5W0v110eAvWpBAFmssLiQIU2VYE/CuNhxncGbwcS1tt8zOmRTvZyXFayr8BBF//qe53d3VOv74FIJZiSuaPyvGTjFJH+SaWkNOz2/wNRIlxb//UUthxmiGrJG14qAQIfCYtTivMidRZ4wIGho7FYHPa8fJ5l0sLYbqaNa30qOUasGA4G4TTz1RW2GDQmUS6aUAmyBMyHW4xRD7ndkgBPjfFP0cBbc9TKqvUUVv8yteCaTpWTaTfPEb8k38v2q1L+H3Z6EFzSeXRyY513ZPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DKWyoluHVpKcSepPU2BRhI4Koh17NOHqNmabhooA4bg=; b=KNX5MzjWY8xlMtU4/wLSbohq2HSjzYI5ELL/jGQVwgwAXC3GpFAf67/RpT9PymUoEF8cz9YAvli6yN0KIY6Vc9ybjSASpvTtZA3Qmotjv3no6hKDVjB64cgbCPKleU49M72y2oj15CouCPtfycunb+WOlrvxe2053GWRAbXSTo0= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM0PR10MB3075.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:15f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.23; Thu, 26 Nov 2020 16:32:26 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.036; Thu, 26 Nov 2020 16:32:26 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS , "hans.aschauer@siemens.com" , "steffen.fries@siemens.com" Thread-Topic: draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality Thread-Index: AdbEEJQzM48/Y2oGSH25fNh+kafNcQ== Date: Thu, 26 Nov 2020 16:32:26 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-26T16:32:25Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=789c2574-788b-4fdc-ad43-da437c957f02; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 166e1bfc-8a72-41be-4971-08d89228dc51 x-ms-traffictypediagnostic: AM0PR10MB3075: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s89HPqR6X0UxFyWqq2nweGyTOKg2p4lBkm4Da9iel9+BHPSxTAy5cVZn1AzicNgsCaU3rxFbgfsn90OWQFnqK/W+W2iHq3VpPAK3u+1f2VZBcQx0yftkpOvGQU0B1rWp5T+eBaM1WoUJ4yOT8SHmwfb+UetLpMZcKPe5nJk3cGXtNeQkom+O2CtG4GWE6WYjJJAd4Tj1+c1F9bLMxDdBPSWpToZ07hI1j/C/FPl+d2q+4P93F7ipFn6Tc8r5eup+BP+kqPMcfS2/uueTUEZTv3gSWG1JeqUmQe6g+uSRLtTVZI44xA7AuH9KDQSSZ/tf x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(396003)(366004)(39860400002)(8676002)(6916009)(8936002)(478600001)(83380400001)(7696005)(76116006)(64756008)(66476007)(66946007)(66556008)(66446008)(66574015)(52536014)(55016002)(186003)(2906002)(71200400001)(55236004)(15650500001)(4326008)(6506007)(9686003)(26005)(316002)(5660300002)(107886003)(33656002)(54906003)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?vQip5ceyQRUbNNEj9sGhvXdWpsdcJ9xyMnk1kSIdeGxvQmCKXp+fhg+KZR?= =?iso-8859-1?Q?OCeN9UJD2Nz70jvBqG4OE+kp66FFiA+GFtQeeRcm9ttF753CABUEO75p/l?= =?iso-8859-1?Q?2p0CMfGRErs1Z5KjzDzoIxd4hw5rEguV+lYNMf7f70lXVcoHSpWys88sSa?= =?iso-8859-1?Q?TdL1IDLY041r3o6q8+SuiXYeAhAnAsEeFGFOicfiTCkgsxuq7xq1sMwydH?= =?iso-8859-1?Q?Fo87oXoxLBEIqr+5aE8M1rt3hC4VSd/n6+1PjcY/RGJgRkIkQJHSykamLk?= =?iso-8859-1?Q?zgG2VtelXTIx3vjn9QL1LTYoWF3igczdzDnmTYM5pHbI6SsVGgahXJ3L/k?= =?iso-8859-1?Q?8ae9BSj6uc0MktBYeHQgQ93xdic+eQxDKnv+sHh1fb4vKu6OMaj2SkjS7+?= =?iso-8859-1?Q?y0jAIVg0QLpMYpeJKTwIU2WPTGngEKTF6Xh7vk8OJMcyBFuvyfUrh6ekdU?= =?iso-8859-1?Q?q3xbk69bluTXBa5wKZpuh/RpupqVfYajYKc1v8+aocKOBosdrxySAX8qIo?= =?iso-8859-1?Q?S+QKLDBOAJsduB9ZffABEwIg5URP7xSMDMmrffYdJbU6t0Th2+xvhwi4p+?= =?iso-8859-1?Q?ChF3UJeyjfFAUVW6/EDgqZvXBndnjDgjNbJFGnM8Yz2KzXFHj/eGLiKbd2?= =?iso-8859-1?Q?0JlmzEhmgfGPXEGeBuvdwk456IFZiLWl+SORoGwpQszNxdttD3N+GVYKSD?= =?iso-8859-1?Q?iKxyqKqi5HHFpNbIV8x6liKXl63+LQb/qKjQMu9UfNIck9ppjG89Gr4QiH?= =?iso-8859-1?Q?KQoxWMPnFUeADJTa0dn6hNqgH65M1pLplw/SNNbHcz9E7ox06vQXgg2gC1?= =?iso-8859-1?Q?4banjU2LB8w1+0+Hp5AX2RFiMfYW61dmxMz/tmrX5kfWpSScZn27TT70bF?= =?iso-8859-1?Q?DHa8USQgg330f3Islege6luHlTmRyZczlgDHU758owt18qDHiiHuZVoyY1?= =?iso-8859-1?Q?Y19kwYMA7nVwm5vRXXBMlT4GnaECePaCo5eaXmWWAuoy+2xS3cActMVrcX?= =?iso-8859-1?Q?7bl95FGYaVLtRr9yhCcqxtXazH8cxDs6YFVC3B?= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 166e1bfc-8a72-41be-4971-08d89228dc51 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 16:32:26.4217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3ujrbl+9LAnl6prUHjhLLwDISCV6lXCMMgCYN+N6bEnVRRWoTrbp7WthNvXjZvh5W5jIvIDE8+f1iQjDv4DmxnE0/NWWXFlBn7msGZBjKxk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3075 Archived-At: Subject: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 16:32:44 -0000 Russ Driven by the bitcoin business, highly specialized ASIC speeding up hash ca= lculation are available for a relative cheap price. Therefore, we would pro= pose to further update RFC4211 Section 4.4 as follows. Add a sentence to the end of the first paragraph of Section 4.4 "The security of this MAC depends heavily on the entropy of the used passwo= rd. Using one-time passwords also improves the security." Add an update of the explanation on iterationCount "iterationCount=20 identifies the number of times the hash is applied during the key computati= on process.=A0 The iterationCount SHOULD be as large as server power allows= , typically at least 10.000 iterations (see recommendations in [NIST SP800-= 63B] section 5.1.1.2)." Add this paragraph to the Security Considerations: "The security of the password-based MAC relies on the number of times the h= ash function is applied and on the entropy of the shared secret (the passwo= rd) used. As ASICs providing HW support for hash calculation are available = for cheap prices, the value of a high iterationCont is limited. =A0Therefor= e, the entropy of the used shared secret is crucial for the security of thi= s MAC function. A high entropy can be achieved by using computer generated = shared secrets, e.g., a randomly chosen shared secret with 10 characters of= fers a entropy of=A0 59 bits and with 20 characters offers a entropy of 118= bits, assuming an alphabet of 60 characters. The use of one-time passwords= also increases the security of the MAC, assuming that the transaction is c= ompleted before the attacker is able to break the shared secret (offline at= tacks)." What do you thin? - Hendrik Hendrik Brockhaus Siemens AG Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann= Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive= Officer; Roland Busch, Klaus Helmrich, Cedrik Neike, Matthias Rebellius, R= alf P. Thomas, Judith Wiese; Registered offices: Berlin and Munich, Germany= ; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684= ; WEEE-Reg.-No. DE 23691322 From nobody Thu Nov 26 09:47:26 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A27F3A158D for ; Thu, 26 Nov 2020 09:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0O3WCeJNqOz for ; Thu, 26 Nov 2020 09:47:23 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951973A158A for ; Thu, 26 Nov 2020 09:47:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DFBC1300BB2 for ; Thu, 26 Nov 2020 12:47:12 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 12J7Y31Ihazk for ; Thu, 26 Nov 2020 12:47:11 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 0B918300A48; Thu, 26 Nov 2020 12:47:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Thu, 26 Nov 2020 12:47:11 -0500 Cc: LAMPS , "hans.aschauer@siemens.com" , "steffen.fries@siemens.com" Content-Transfer-Encoding: quoted-printable Message-Id: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> References: To: "Brockhaus, Hendrik" X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 17:47:26 -0000 Hendrik: > Driven by the bitcoin business, highly specialized ASIC speeding up = hash calculation are available for a relative cheap price. Therefore, we = would propose to further update RFC4211 Section 4.4 as follows. >=20 > Add a sentence to the end of the first paragraph of Section 4.4 > "The security of this MAC depends heavily on the entropy of the used = password. Using one-time passwords also improves the security." I would prefer to say: "The password for this MAC SHOULD NOT be used for = any other purpose." I think this avoids potential issues with repeated = requests. What do others think? > Add an update of the explanation on iterationCount > "iterationCount=20 > identifies the number of times the hash is applied during the key = computation process. The iterationCount SHOULD be as large as server = power allows, typically at least 10.000 iterations (see recommendations = in [NIST SP800-63B] section 5.1.1.2)." Good idea. > Add this paragraph to the Security Considerations: > "The security of the password-based MAC relies on the number of times = the hash function is applied and on the entropy of the shared secret = (the password) used. As ASICs providing HW support for hash calculation = are available for cheap prices, the value of a high iterationCont is = limited. Therefore, the entropy of the used shared secret is crucial = for the security of this MAC function. A high entropy can be achieved by = using computer generated shared secrets, e.g., a randomly chosen shared = secret with 10 characters offers a entropy of 59 bits and with 20 = characters offers a entropy of 118 bits, assuming an alphabet of 60 = characters. The use of one-time passwords also increases the security of = the MAC, assuming that the transaction is completed before the attacker = is able to break the shared secret (offline attacks)." This seems like a good addition. Russ From nobody Thu Nov 26 10:23:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8FB3A160F for ; Thu, 26 Nov 2020 10:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tNe4xmruGo6Y for ; Thu, 26 Nov 2020 10:23:48 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D883A160E for ; Thu, 26 Nov 2020 10:23:47 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id k26so3194666oiw.0 for ; Thu, 26 Nov 2020 10:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O+svJ74O+tDMi+7qghmiVCrLUwRO2ZR/JYkGvGs0fLg=; b=IKccjHcviLpQVs7JESU+TiHb3FrCDsoxOUrZYJKLgltOtbHCeklPq3ITghI1+FCpWN rtqB6Df+/JhdeJiMxSrQ2fVf3ru2J21wK2IKz1e5tfZbLYVexm43d9HFAcI82kI5PJ0R dt4w605XqJ4TNQgA1GofyHityDrPJkHwh3si+trKfvghfpIwT5upgkjjVb65U0SeqNQ7 djxf8M+JW9H9yta1jmuUm5lJZfKHk0i/StJztCVNZsyuR1Vb4urTu6QxBoykrSnq1w0W UUo1I88tYslmh0qqE7bK+GNmI5owACesZ0f+xGBesWsGOuDXD3scaFdI5yCsmRW9TD77 0Xyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O+svJ74O+tDMi+7qghmiVCrLUwRO2ZR/JYkGvGs0fLg=; b=GCODcShLsrCmF2hS/nmlWaTFs+edffD0BTFKJlcBWYnzL5rDsrp7uEE/Buh2YiZHfX YA+RYaUJtrvp2qb9Oob8JaPZ3oPrps2NG/NzDqPyKh7M3qONwOyXcX/pN/z8mCIgUA+X lDcazN6vlzntM3T4k0VtH2FpSMDRRRkX0SmPsQWRI9IF16ZjY71gg/0IxR5cBA8P5LUH gDqL3RxZSst/7upN9r/CD845c2aUMPGNBf6IgsEZtkdWAOkuJJN+ns+5q1jyP/6XQHuP uRpUbW7+4bYyzB5u4P1N/KSfOHqB1yZ5fla75MXmIrQWenkdvXb/kFw/OJT6BEfg7o5G 0Zwg== X-Gm-Message-State: AOAM531GXiTy813TFwsK+geurjPhu2xjg3TUV70Kq4rQL4N5AxaOcc0c BzFVRqwNFNe9nqM8EQ0U1u1fRAAqOIvCYhCm4wY= X-Google-Smtp-Source: ABdhPJymYjXVr0tNnbysbW7o4O9PVIGYV271Zs2rm4N8qUjE1lNlb6/Jxb5rYVnztKz+5/GMSer+EWlsNghrw6OFf0w= X-Received: by 2002:aca:3956:: with SMTP id g83mr2764721oia.143.1606415027227; Thu, 26 Nov 2020 10:23:47 -0800 (PST) MIME-Version: 1.0 References: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> In-Reply-To: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> From: Jonathan Hammell Date: Thu, 26 Nov 2020 13:23:36 -0500 Message-ID: To: Russ Housley Cc: "Brockhaus, Hendrik" , LAMPS , "steffen.fries@siemens.com" , "hans.aschauer@siemens.com" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 18:23:50 -0000 Russ, Hendrik: On Thu, Nov 26, 2020 at 12:47 PM Russ Housley wrote: > > Driven by the bitcoin business, highly specialized ASIC speeding up hash calculation are available for a relative cheap price. Therefore, we would propose to further update RFC4211 Section 4.4 as follows. > > > > Add a sentence to the end of the first paragraph of Section 4.4 > > "The security of this MAC depends heavily on the entropy of the used password. Using one-time passwords also improves the security." > > I would prefer to say: "The password for this MAC SHOULD NOT be used for any other purpose." I think this avoids potential issues with repeated requests. > > What do others think? I think Russ's proposal is more clear for implementers. The proposed text to add to the Security Considerations discusses the entropy requirements and suggestion for one-time passwords. I agree with the other proposed changes from Hendrick. However, I'm concerned about the ASN.1 for PBMParameter Section 4.4 of RFC 4211 for the following reasons. If one wanted to use scrypt (RFC 7914) for the owf, there is duplication of the salt parameter and the iterationCount in PBMParameter would no longer be relevant. One might even want to use Argon2 (draft-irtf-cfrg-argon2), but unfortunately there is no ASN.1 module in that I-D to specify parameterization. I realize that backwards compatibility needs to be maintained for PBMParameter so those parameters cannot be made OPTIONAL, but perhaps some guidance like the following should be added? "If a salt value is specified in the AlgorithmIdentifier parameters for owf (such as in [RFC7914]), the salt value in PBMParameter MUST NOT be used and it SHOULD be the zero-length octet string. Similarly, if the mechanism specified in owf has its own cost parameter for deriving a key (such as in [RFC7914]), then the iterationCount value in PBMParameter MUST NOT be used and it SHOULD be set to 0." Jonathan From nobody Thu Nov 26 10:34:15 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BC03A0115 for ; Thu, 26 Nov 2020 10:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GrmmkDTMUMz6 for ; Thu, 26 Nov 2020 10:34:12 -0800 (PST) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::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 3DCAF3A0114 for ; Thu, 26 Nov 2020 10:34:12 -0800 (PST) Received: by mail-oi1-x234.google.com with SMTP id w15so3138818oie.13 for ; Thu, 26 Nov 2020 10:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=c6eLinUDMutXpWSPWl67iOpJP+eCrLFFn0fff07lANg=; b=sQ7AmOiYLrNlQZcblA7CKeIXQgh4UkN105Jp2dy4DswisEZQpek6W+sDPbPo2LQ7EX tiFT08/Nt5oaz7zn+0NUJcVGvH8fCrvXd3WYN3gK621AL90mKrPVs3bEObwRUJtJP3Tt PjCAyYACs9VEX51QRUno3zdOq/VV/V8jQb8QCgQCpXE+28zjtjpG7PAr5os0RyIepLEU +wk36WLnuyt17WZ9qpuzPNqEYXCc2MwqCZo+JRLkHIZ0GjoWTMryg1bjmux9sozw+Zxp WeZF8QJD8ommxAgV5G4eOZaS72GtNB3IPd7eFBtBK5n7t4qYnuYjh+LG25CAaxFcbIZ6 EEaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=c6eLinUDMutXpWSPWl67iOpJP+eCrLFFn0fff07lANg=; b=WtCbejcfirE11iTeB4OaokficpB10J31B3BAmvjTijoy/2w3ZIaJtgjdgZLSXO7Wlb b3eDPmpKBPviT3KCExuiwvNPGNF+Jsy9gIhqir3cZejOej51PeuwIQL7h3ONw/Rlu2mY P7fQ2QR4Cn9v9U6q3ypfVNtPwY6GM0dbRXJ9pB5prFiAboCIquRDW9413QA/dPvNlWka nJbBo8oBkudQpkh4jrV5Rgb1+RMeOOdQcGIOuZNz6u4gLzTL29uxOq1PIJkvwRb79Tym Sj0PIkGb/NK1zPVjqdgsDX6pI54ge5PbUEj+g/ANUhyUhopd1O6pVq+zckSEQPnF2rgv tDLw== X-Gm-Message-State: AOAM531/Azkvkce+5XfziE1x3nYCM9TVi2JOns74GMOegEzSegdn+RJb Xblh67GdRydrMESlOtYFF08vPkGb+l56JQNu15Q6d6Ub1pA= X-Google-Smtp-Source: ABdhPJy6Hg+r5BFSqUU6BXcjqqSY0zEcD6WZhiPHI+/VBKiD4sb03xH2+jPXAAKnId6FKy5o7IWijVYsTdZpGZDIjBc= X-Received: by 2002:aca:3115:: with SMTP id x21mr2797093oix.101.1606415651699; Thu, 26 Nov 2020 10:34:11 -0800 (PST) MIME-Version: 1.0 References: <39530D49-453C-48F0-B573-AEAA73AB6BA3@sn3rd.com> In-Reply-To: From: Jonathan Hammell Date: Thu, 26 Nov 2020 13:34:00 -0500 Message-ID: To: Sean Turner , SPASM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Call for adoption of draft-housley-lamps-crmf-update-alg X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 18:34:14 -0000 I support adoption. (Now properly sent to the list, sorry about the duplication). Best regards, Jonathan On Thu, Nov 26, 2020 at 1:32 PM Jonathan Hammell w= rote: > > I support adoption. > > Best regards, > Jonathan > > On Mon, Nov 23, 2020 at 10:37 AM Sean Turner wrote: > > > > I support adoption and am willing to review. > > > > spt > > > > > On Nov 20, 2020, at 15:00, Tim Hollebeek wrote: > > > > > > We talked about Russ=E2=80=99s other draft earlier this week that add= s more appropriate modern algorithm choices for password-based MACs in the = Certificate Request Message Format (RFC 4211). The draft is here: > > > > > > https://www.ietf.org/archive/id/draft-housley-lamps-crmf-update-algs-= 01.txt > > > > > > Please indicate by December 9th whether you support adoption of draft= -housley-lamps-crmf-update-algs by the LAMPS WG. > > > > > > -Tim > > > > > > _______________________________________________ > > > 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 Nov 26 12:57:47 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593DC3A0FBB for ; Thu, 26 Nov 2020 12:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VGTa21nhUTcb for ; Thu, 26 Nov 2020 12:57:44 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 A0AE93A0FB8 for ; Thu, 26 Nov 2020 12:57:44 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id q22so2647097qkq.6 for ; Thu, 26 Nov 2020 12:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=aPAhlhUIaRvHAYgNgAf35QfZnBOkEkC55QhIhy3iLS4=; b=r2z3h1ALnUeD+qB55HkST7xMQFhTlUbvTGz2ZMjLD4Jj9WagCiSnmrsLT+axE4QBFo xPTcod3lwaExKt1UspmInug3QTu3RldbLsn6yw2hP/m+UcfDPKrt0ff5+9q6Tmw5P84C o8yTnwhVCOMldichdJ04tZbLE/HGiXPQKOyvzOM8CR+F7d5zwmPGJ2hW3ZluroeDjY82 cG+xb2fZulCieyUaKeo40s16guE5uju0Di9/42iCw2qWkCJ0hvExqfAM9zds5+pB8xyP YXUPVd4xAkMPLMzh629MGCgfyS/PHqWpCowCsHPlOAAbEWmtOLVrgsfYdBt5yR+ppj8h FJFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=aPAhlhUIaRvHAYgNgAf35QfZnBOkEkC55QhIhy3iLS4=; b=k+f94daVf5yKmCepSaXvmFG+KZaIjIJXSusHdbnigwx9BQu4RsZ44xKbr0ER5A1tdi opmKc1oaEXNKu9QWA6lk//vsNbI6sQ7vJBsC1Up/reY/h0eiRsANkf/ReKtAZUbaUMuL BIxdtuO67ocLKcm/vIVGNxyKuRWBJmW8GT5f20NE0Zvvxhft5b8Rsk7yfMQRPUoGsHPp drAHqdv+o9OIMO6yQMCVTdf5ukwO/71xH07ih8kXIONJ55WsoJ6/d6G+9j8F5qFp4cA/ E+snOH1lhN0E+RpscxAicSkChqvdmuOC7ab8v6PGx4QyCYS2WyVYDvnmsRvIFTdHr5Pb eFrQ== X-Gm-Message-State: AOAM5316XXo8TVnIrV1W3eLkY6qTHxHo9werornnsJql1yrOJrLsPBRg nTdqlYesTMNepWkFH2PRZ+yXon1j+ew= X-Google-Smtp-Source: ABdhPJyXTo6CGYpRZ4w+FLdyn0/laM42d1k8XAx+Pk4JAQ9hjBwBVDBGaukAFRP/eQ4/rtpZIPWCIg== X-Received: by 2002:a37:a611:: with SMTP id p17mr5018039qke.51.1606424263235; Thu, 26 Nov 2020 12:57:43 -0800 (PST) Received: from ?IPv6:2607:fea8:8a0:1397:fc5f:12b:d173:619a? ([2607:fea8:8a0:1397:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id i9sm3630641qtp.72.2020.11.26.12.57.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Nov 2020 12:57:42 -0800 (PST) To: Russ Housley , LAMPS References: From: Rene Struik Message-ID: Date: Thu, 26 Nov 2020 15:57:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B38F081F01425D56DBD18BAE" Content-Language: en-US Archived-At: Subject: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 20:57:46 -0000 This is a multi-part message in MIME format. --------------B38F081F01425D56DBD18BAE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Dear colleagues: Do you think supporting ECDSA25519 would make sense as well? This is well-defined and non-deterministic and also can use existing Curv= e25519 ladders under the hood (see [1]) as well as existing generic hardw= are supporting short-Weierstrass curves (see [2]). Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve dra= ft [3], it seems this could just be used without further ado. Best regards, Rene Ref: [1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-represent= ations-14#section-4.3 [2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-represent= ations#section-6 [3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-represent= ations =3D=3D [excerpt of draft minutes] Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RSASS= A-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is gain= ing support. Russ (and several in chat) suggested dropping DSA. No objec= tions. On 2020-11-25 5:43 p.m., Russ Housley wrote: > https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00= > > Please send a note is you see anything that needs to be corrected. > > Thanks Jonathan. Your notes were excellent. > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 --------------B38F081F01425D56DBD18BAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Dear colleagues:

Do you think supporting ECDSA25519 would make sense as well? 

This is well-defined and non-deterministic and also can use existing Curve25519 ladders under the hood (see [1]) as well as existing generic hardware supporting short-Weierstrass curves (see [2]).

Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve draft [3], it seems this could just be used without further ado.

Best regards, Rene

Ref: 
[1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-14#section-4.3
[2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations#section-6
[3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations

==

[excerpt of draft minutes]

Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is gaining support.  Russ (and several in chat) suggested dropping DSA. No objections.




On 2020-11-25 5:43 p.m., Russ Housley wrote:
https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00

Please send a note is you see anything that needs to be corrected.

Thanks Jonathan.  Your notes were excellent.

Russ

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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--------------B38F081F01425D56DBD18BAE-- From nobody Thu Nov 26 13:26:41 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507163A1034 for ; Thu, 26 Nov 2020 13:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BDRry30EI1V for ; Thu, 26 Nov 2020 13:26:38 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F5D3A1031 for ; Thu, 26 Nov 2020 13:26:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C524A300B2B for ; Thu, 26 Nov 2020 16:26:35 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LtN-xTTwleRT for ; Thu, 26 Nov 2020 16:26:33 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 03D46300A48; Thu, 26 Nov 2020 16:26:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Thu, 26 Nov 2020 16:26:34 -0500 Cc: "Brockhaus, Hendrik" , LAMPS , "steffen.fries@siemens.com" , "hans.aschauer@siemens.com" Content-Transfer-Encoding: quoted-printable Message-Id: <314553E7-B3D9-43B4-B775-31482C5035C6@vigilsec.com> References: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> To: Jonathan Hammell X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 21:26:40 -0000 Jonathan: > On Thu, Nov 26, 2020 at 12:47 PM Russ Housley = wrote: >>> Driven by the bitcoin business, highly specialized ASIC speeding up = hash calculation are available for a relative cheap price. Therefore, we = would propose to further update RFC4211 Section 4.4 as follows. >>>=20 >>> Add a sentence to the end of the first paragraph of Section 4.4 >>> "The security of this MAC depends heavily on the entropy of the used = password. Using one-time passwords also improves the security." >>=20 >> I would prefer to say: "The password for this MAC SHOULD NOT be used = for any other purpose." I think this avoids potential issues with = repeated requests. >>=20 >> What do others think? >=20 > I think Russ's proposal is more clear for implementers. The proposed > text to add to the Security Considerations discusses the entropy > requirements and suggestion for one-time passwords. >=20 > I agree with the other proposed changes from Hendrick. >=20 > However, I'm concerned about the ASN.1 for PBMParameter Section 4.4 of > RFC 4211 for the following reasons. If one wanted to use scrypt (RFC > 7914) for the owf, there is duplication of the salt parameter and the > iterationCount in PBMParameter would no longer be relevant. One might > even want to use Argon2 (draft-irtf-cfrg-argon2), but unfortunately > there is no ASN.1 module in that I-D to specify parameterization. I > realize that backwards compatibility needs to be maintained for > PBMParameter so those parameters cannot be made OPTIONAL, but perhaps > some guidance like the following should be added? >=20 > "If a salt value is specified in the AlgorithmIdentifier parameters > for owf (such as in [RFC7914]), the salt value in PBMParameter MUST > NOT be used and it SHOULD be the zero-length octet string. Similarly, > if the mechanism specified in owf has its own cost parameter for > deriving a key (such as in [RFC7914]), then the iterationCount value > in PBMParameter MUST NOT be used and it SHOULD be set to 0." I do not think I agree. If you want to use one of these other = constructions, wouldn't completely replace id-PasswordBasedMAC? Russ From nobody Thu Nov 26 22:30:58 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696F3A1256 for ; Thu, 26 Nov 2020 22:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=jXAJBI+G; dkim=pass (1024-bit key) header.d=primekey.com header.b=jXAJBI+G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8JHS8AiWLJI for ; Thu, 26 Nov 2020 22:30:53 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370E53A1259 for ; Thu, 26 Nov 2020 22:30:51 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 78A1F6AA5030 for ; Fri, 27 Nov 2020 07:30:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1606458648; bh=7C8p4kL5/YpjGpzITjyDvjZvRivrylUvcrj539OYrRM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jXAJBI+G4BYYGrPOX/p0l/CL8Up+xbkBWvA2GqerKHPd0vo61c2TOy/R6mfDec7JV Hg5Pc8zvlA90kiaXeoUpsORH/vr4eddMO/HLeBIJEALGi3HVMeQyhW/aLeJwsS11J8 QUkEc3ioSGgeom5J5LSHF3XMmQhlI95v9P1nH+HE= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 596536AA4E09 for ; Fri, 27 Nov 2020 07:30:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1606458648; bh=7C8p4kL5/YpjGpzITjyDvjZvRivrylUvcrj539OYrRM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=jXAJBI+G4BYYGrPOX/p0l/CL8Up+xbkBWvA2GqerKHPd0vo61c2TOy/R6mfDec7JV Hg5Pc8zvlA90kiaXeoUpsORH/vr4eddMO/HLeBIJEALGi3HVMeQyhW/aLeJwsS11J8 QUkEc3ioSGgeom5J5LSHF3XMmQhlI95v9P1nH+HE= To: spasm@ietf.org References: From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <1b53e44d-b0fa-88cd-63dc-2d3d149fbc52@primekey.com> Date: Fri, 27 Nov 2020 07:30:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 06:30:57 -0000 My two cents. Working with hardware security modules it's a bit of a pain as it is with EdDSA. As PKCS#11 supports it in PKCS#11v3 which is not yet widely available in implementations you have to do custom coding for each hardware module. Adding more options for users, that are not broadly available makes it confusing and hard to make (cost effective) choices. Therefore I would not like to add algorithms that have not yet gained wide support. We also see that Ed25519 is gaining support (P11v3 is making inroads), making that logical to add. I also have not used DSA, or heard any requests for it, for about 10 years or so. I support dropping it. Best regards, Tomas On 2020-11-26 21:57, Rene Struik wrote: > Dear colleagues: > > Do you think supporting ECDSA25519 would make sense as well? > > This is well-defined and non-deterministic and also can use existing Curve25519 ladders under the hood (see [1]) as well as existing generic hardware supporting short-Weierstrass curves (see [2]). > > Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve draft [3], it seems this could just be used without further ado. > > Best regards, Rene > > Ref: > [1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-14#section-4.3 > [2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations#section-6 > [3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations > > == > > [excerpt of draft minutes] > > Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is gaining support. Russ (and several in chat) suggested dropping DSA. No objections. > > > > > On 2020-11-25 5:43 p.m., Russ Housley wrote: >> https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00 >> >> Please send a note is you see anything that needs to be corrected. >> >> Thanks Jonathan. Your notes were excellent. >> >> Russ >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Thu Nov 26 23:12:04 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CD43A136A for ; Thu, 26 Nov 2020 23:12:03 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 2l8Z0k1L_EMQ for ; Thu, 26 Nov 2020 23:12:01 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80042.outbound.protection.outlook.com [40.107.8.42]) (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 504103A1369 for ; Thu, 26 Nov 2020 23:12:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gdZJ08e9H6VWl+aYY8dBy+lQxP3ynzV0UknJE/V1oIn97E48xSs/RnC/uQedRZ98KoJiCMdAsuaAb1RZWPupq41begccxoWM3cHE7JHYGQlJe3Jvxk+4BPR6kKtMLvZ8AAjr7AP5mhKMNDlYLaNb0EqFzvc5JUNgspHhMQ0SHtwhj/MUTB/dxIWF3iwwDgBgsQYv6IFM8TJASRiIN2Oi8RwGEGj5NQCcq5cmFSyc0pko6rUMxwoHPpOgGpTrNGwAIHb8OEm3XDruEK3ny04JJDD6wPaAhw4PAxIMi+PPpOr9n6fA+aMuai1OX3ApJ7YhLwjVkX1dp9S5WnysnYhvFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mm4nYbg0hHzxLBPQ6FRfMCW1mFbYFcsEXZNND6S/RPs=; b=eAbcQh9AAJM+nCvhf4cFMCS+UMTryOniA+WhvIvg9yrxRCo3CRfmwH2Ai7bdC/nbrhYyoOEE7JsPr/HaABmrWzOvoWFLXOAdxZ7d9GyaqOI8OsJWPG2XgIB3mzpYWwIjjpwHf6rJA3HIP5hePKS1woWBEbPUjYI7jBTcSgb0i6rqWSh5AO6tnLpeQOYEYzpsbekkwyNTcrKMAJhqcVLZWEFDuVcN54dxstDRxxzuKlQhKtrSW1uKehaWSyq/aciEhNQ5lMYSO6ytxZTH1mUMlQeh4XddgFtAbBdIX3UsnnuHueoUakFbizmr+n7ksGgP+cXX6+XNNUTO5CJx6a86HA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mm4nYbg0hHzxLBPQ6FRfMCW1mFbYFcsEXZNND6S/RPs=; b=JugdXkBd84juoMWaWEguvXhxpjXOiUqc3T/adk7Sf8NI4QNnAeilnaKoBgxQOTBiV2zGIl9TwaIf0dzvvfO7PriQnpr6Qr2yJ4g4jhwB49oVJODufxYfu8laM7PcM62JRZPgi8GEb0e+pMwmEKhrFqjw++5T12NVUjmW5c8GZmk= Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM9PR10MB4037.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:1fe::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Fri, 27 Nov 2020 07:11:58 +0000 Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::99d0:2508:a9e9:3149%6]) with mapi id 15.20.3564.036; Fri, 27 Nov 2020 07:11:58 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: LAMPS , "hans.aschauer@siemens.com" , "steffen.fries@siemens.com" Thread-Topic: draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality Thread-Index: AdbEEJQzM48/Y2oGSH25fNh+kafNcQAC5aWAABvoZfA= Date: Fri, 27 Nov 2020 07:11:58 +0000 Message-ID: References: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> In-Reply-To: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-11-27T07:11:56Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=4d4870a6-a0c0-4b4c-b666-35435423be6f; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.180] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f0053998-a3d2-4c16-a2e6-08d892a3bb04 x-ms-traffictypediagnostic: AM9PR10MB4037: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7oI0vgoxrtxRG1AuBSt8FpilBRhMaYupJnhjMt4elWS5fmJ5L3NV9bhkKFKYh3+v8kkYTZR+HajazCQmWY0vqB6yeOzb53rHuBWOP0QNKUY+qyLl2N0a+r/UtHZz4flTaaq3actyhJQS6twxBV684li7U2sLqC7WiQ4m9GdbL8wmgNf0rhM9m0+v9+eF+/dV54s3klkWj8nRVNcR3UXAzVm7LB+l+Oc9M/4ZNZAMx4K8mPk+LKaL3aZW2xaj8qk9yH9epp765PhWCfDlDpwx8O9r6lNyrxI4tdGSkJZibxcv8o0fNEDzjo2+oTmfBzm/XzaYGs2Hr654u5ze50TE8A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(33656002)(7696005)(55236004)(107886003)(66476007)(5660300002)(15650500001)(66446008)(64756008)(66946007)(66556008)(76116006)(6506007)(52536014)(6916009)(71200400001)(86362001)(478600001)(54906003)(8676002)(186003)(4326008)(83380400001)(316002)(9686003)(2906002)(55016002)(8936002)(66574015)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?gS3qQ4l6NKR3YPqfXu1+Om+ttbkdDLqjjBEWakyELVKuKRcFCRk8z7eOU/gY?= =?us-ascii?Q?f7AszA0H8Azd2m0WcAydz5CWrcWR1PLaaYUdvNSEO3o2I2J4CPMPinZy1hO1?= =?us-ascii?Q?Y3tDrwuaP9JLSfk14qn6F53KRI9XKEIe2EJhIeLBdoLa2M1yKhJA02dFkYBT?= =?us-ascii?Q?D7EaGRyjWsj2eFCIpGMEJqAHBn6Y4PTsy6UR13KFPmrWq3w0a/C2uPiKHUze?= =?us-ascii?Q?YGy6TKwg95fwZZcPjWDI/GQeW6OdK890x5FiUggQCkE7gvdwEcnalLiIrF4C?= =?us-ascii?Q?wdXSBQHBan1Swzz9BogEfDYROTgEl2+g+UCo3CtfQXIIi/h42LHK5iNXYngw?= =?us-ascii?Q?5NS4E6WLPpoOCCMJHD8KKyyPNGY9sasCOGZtg80LYjBT1K9nTuIC5g7Jebcb?= =?us-ascii?Q?Pg81S2qMvCkEsnoj4YEC4NofFHbHeP6446pF2xtyQ9Ku1K9ed340oMK+DxtT?= =?us-ascii?Q?F7QBOxabE7aFAm1VP8JuzrooCcZDoQoSPasRYAbXoVMoYr32IS43fzxg62v2?= =?us-ascii?Q?kx9T0B6XzF3vd8dJw2FpRdfZx5OKqYzmcocaUcRJRuCCzu/nsX51j874cHLk?= =?us-ascii?Q?M6+DOaqGlezKIx7KnEMO92+4CiIOhxyPCsqwhXX+asJNpPW3RBSMzuUGmixb?= =?us-ascii?Q?7tX5xmSPkzK+SdpDVSFbTbYrHKqzUFxSUTjxuoGc0KdPyXlCa8jTrDlKhqKs?= =?us-ascii?Q?SvFQGelsrJ9C1jLo+RFkOSpBzI504clfYex5svLjeA5fNTleIwJ2hsKY2Fk3?= =?us-ascii?Q?3RYloVSrAxUv1Ry7lDdjwwZlZYPVIMaZEy+F961WqdurzCet5CyTko7GKo0l?= =?us-ascii?Q?Sb2+rUSvGIN5pl14lNSdohkLiD8BTQ83ZqH1vQ24W/AM6SKR3tBQLsmKvYkD?= =?us-ascii?Q?+kuKjzI9x3payndw5U5gc1r7+ywguTRSpb8ocipZlErhL3FNJX6B65OOEWY9?= =?us-ascii?Q?1FTX02K9sQZ0nnA20LDnpMS4pmFnED8I0gcPvFpXDqOxD2JGQOPHT0gZYlYS?= =?us-ascii?Q?Z2la?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: f0053998-a3d2-4c16-a2e6-08d892a3bb04 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 07:11:58.6473 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N2XDCqeBwCb/wgoXMRkZgBETtc1fM8jw85IJWC9WJNOgn9Hk441um1hGo+vYfg2KBMn2H9+JiuRTQScRcfLXvxvNgQOoxXTitmPIpW1XuaE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR10MB4037 Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 07:12:03 -0000 Russ > Von: Russ Housley > Gesendet: Donnerstag, 26. November 2020 18:47 >=20 > Hendrik: >=20 > > Driven by the bitcoin business, highly specialized ASIC speeding up has= h > calculation are available for a relative cheap price. Therefore, we would > propose to further update RFC4211 Section 4.4 as follows. > > > > Add a sentence to the end of the first paragraph of Section 4.4 "The > > security of this MAC depends heavily on the entropy of the used passwor= d. > Using one-time passwords also improves the security." >=20 > I would prefer to say: "The password for this MAC SHOULD NOT be used for > any other purpose." I think this avoids potential issues with repeated > requests. >=20 My goal was to make sure that the password is not reused for another activi= ty, including a second enrollment to a later point in time, to thwart offli= ne attacks. Saying ' SHOULD NOT be used for any other purposes' addresses p= art of the issue better than my wording, but does not express prohibiting t= he reuse for the same purpose. Hendrik From nobody Fri Nov 27 06:41:29 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0047C3A0E5A for ; Fri, 27 Nov 2020 06:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 KtKjs-6pcvWx for ; Fri, 27 Nov 2020 06:41:26 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 2DCE03A0E59 for ; Fri, 27 Nov 2020 06:41:26 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id x13so2403319qvk.8 for ; Fri, 27 Nov 2020 06:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=lXnfngF4ZFeBfL5K2JjgvgXSxqETdLjlQ6Dx54V3DMw=; b=WmFChncLKOV4eIkLpHiTkt0BSJiRAhXQWCpD8ugEF2H3i1v1JHGNbZ6ygIGaOGsvZI K2J5t5rKFQHuWfnoU6mfn74d4YvHDDpUK5xuo/cWG8NwFRYVd1BjWY6iR58ZIoN4GTNA V29VZd1eaGSIEc6GUnpOtp0BPyQrRaD2Njr8Ha4USajsbK0N+MNf/f0BK8sel8BBUc5e oUVoD9CGr2jfgcskTZ0PHlFX3wd0yVc1ZLbqrS7eKHTBOGnRiQ7Si3+z9pDZatiQns89 ixYFyKtXi52ScRuzZzbCSts7nB1hdUddpWRrfIRsPApbBLFPCELbBLWr6fJwkXCOx+IR Zm7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lXnfngF4ZFeBfL5K2JjgvgXSxqETdLjlQ6Dx54V3DMw=; b=TxsM5uBHVf/0Om8rdYabUXjKldFjAm+kNqAihvoqcsYv3xwjAeCbR3HYMPT3j2LdJn hNq1M8oVtB941PHbyZ75DRtLdcHaMupOUW17OL2YRLLt/hWiYspvxSUs9V3b5k4/nCTz 9T2woc7eR750IGAUTkQqmYTwjckjiwUB8xylbq181q5ElIfYIF5wJMYQGcW6sst9l4xp 2ihveEqIJXoIcD5TnflhzIhB32QrluGBKYxyoedKcLDQesKGaPHU9FERzxAkkU08oLPG Pg7VVCKo6PWpqaPXWqgGn1fbqim3otVpGE2/unuw+z6N11hqitfhaIuUAuN3nfapG4cT NVVg== X-Gm-Message-State: AOAM5325QkrwUvt20DeqtsasJGbO5GhfpuZe7y11tRIUOdwi/qH4/rv6 WW1xOHbdH8SRY+r05g5uzQjbyZX1kEs= X-Google-Smtp-Source: ABdhPJzzPz/w8skP29YF6vhcysR88thcF1WHDxamLOoHi+i+BiK37TUc63T2rLwfnHBbJkg5SW8+EA== X-Received: by 2002:ad4:4584:: with SMTP id x4mr8661491qvu.47.1606488084874; Fri, 27 Nov 2020 06:41:24 -0800 (PST) Received: from ?IPv6:2607:fea8:8a0:1397:fc5f:12b:d173:619a? ([2607:fea8:8a0:1397:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id e3sm5927254qts.8.2020.11.27.06.41.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Nov 2020 06:41:24 -0800 (PST) To: Tomas Gustavsson , spasm@ietf.org References: <1b53e44d-b0fa-88cd-63dc-2d3d149fbc52@primekey.com> From: Rene Struik Message-ID: Date: Fri, 27 Nov 2020 09:41:22 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <1b53e44d-b0fa-88cd-63dc-2d3d149fbc52@primekey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 14:41:28 -0000 Hi Tomas: Thanks for your note. It would help to understand somewhat more your=20 "custom encoding" remark. (I do think this would be enlightening in=20 general, since HW insights are not widely available within IETF). Also, I would be curious which version of Ed25519 is gaining support=20 (there are many), since the deterministic scheme specified in RFC 8032=20 has come under criticism [1]. In fact, this motivated my suggestion to=20 use ECDSA25519 and to provide something that at least has been known to=20 work effectively (and without buffering issues). Could you provide a pointer to the PKCS11v3 specification that provides=20 all technical details? (or, is this behind a paywall)? Ref: [1]=20 https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02 On 2020-11-27 1:30 a.m., Tomas Gustavsson wrote: > My two cents. > > Working with hardware security modules it's a bit of a pain as it is > with EdDSA. As PKCS#11 supports it in PKCS#11v3 which is not yet widely= > available in implementations you have to do custom coding for each > hardware module. Adding more options for users, that are not broadly > available makes it confusing and hard to make (cost effective) choices.= > > Therefore I would not like to add algorithms that have not yet gained > wide support. > > We also see that Ed25519 is gaining support (P11v3 is making inroads), > making that logical to add. > > I also have not used DSA, or heard any requests for it, for about 10 > years or so. I support dropping it. > > Best regards, > Tomas > > On 2020-11-26 21:57, Rene Struik wrote: >> Dear colleagues: >> >> Do you think supporting ECDSA25519 would make sense as well? >> >> This is well-defined and non-deterministic and also can use existing C= urve25519 ladders under the hood (see [1]) as well as existing generic ha= rdware supporting short-Weierstrass curves (see [2]). >> >> Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve = draft [3], it seems this could just be used without further ado. >> >> Best regards, Rene >> >> Ref: >> [1] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-repres= entations-14#section-4.3 >> [2] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-repres= entations#section-6 >> [3] https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-repres= entations >> >> =3D=3D >> >> [excerpt of draft minutes] >> >> Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and RS= ASSA-PSS. Russ mentioned that signing with Ed25519 (uses Curve25519) is g= aining support. Russ (and several in chat) suggested dropping DSA. No ob= jections. >> >> >> >> >> On 2020-11-25 5:43 p.m., Russ Housley wrote: >>> https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-= 00 >>> >>> Please send a note is you see anything that needs to be corrected. >>> >>> Thanks Jonathan. Your notes were excellent. >>> >>> Russ >>> >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >> >> --=20 >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 >> >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 From nobody Fri Nov 27 09:47:50 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA043A0AE5 for ; Fri, 27 Nov 2020 09:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 E0swfsyTekPb for ; Fri, 27 Nov 2020 09:47:48 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 5BB363A0AD5 for ; Fri, 27 Nov 2020 09:47:48 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id y24so5358947otk.3 for ; Fri, 27 Nov 2020 09:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ATv08llFUbRoWvK2TfBBnTD+ffJuTGUu/ohCgxeDBTg=; b=kcr+r6smw8/Sgw7b7STfoWyKKXmvXr1IIXQq2Fa4Mx6wVcyfWfyGdocHErj++scdLB Chig37NtcGDUjaGg0T4IlscRdlIv9xPLI35P2d7JFo8YIQJQivGhhZOel7F9sMTx5c3z iUFvSaRpVrWTzLdtGloDkNyL1+SWvbUDya3U/DLjFSUaiTOQmYAlNtlfjzDztn+d8PSR K1lq4/2uQVDEEgQR+d9Q1IVpBzzDsSUBhRdOZ557hGPX6OWv5gKP2aM49sA/UAgjiJYT kPvw3VEcfBSRohZHxvyDBbTwasDErKAY4+y3X8jBFnncL3EvUG32IHBuNNOazl5jY/Gt 04qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ATv08llFUbRoWvK2TfBBnTD+ffJuTGUu/ohCgxeDBTg=; b=SSnUIx5Van/qsNAWMR99Yo76vedX5vMYa0qgMwfZwUan64yZN854SfOHBZLO8EpQ3l o+9NpN+UL+QqKRrYuPkAZrfk1OFvHhPJzNs60MmrwUAaeIZ/1adB17obGl/aTb6T6epj 0HTjfknv42K2GHwfFvhYBDI/moisuK4I063nsxiRLHcc2asobUpfC0zGNfZOq7XOYK8f NssfA9hS/Q6zusjTbtUPYyLsaHtUCoWQC7nujt/JuJKVj3hp0RXcwnc0I50RfOwqUwcf w4LbN7Zpkih1lJM/vxjdWg6vIvpSrk5UF89AJ3eaSjtZa6lXgc6WcPb5Fk3zpNugvZfO z/4Q== X-Gm-Message-State: AOAM530z1MsqXLkrmqlzTL8uQg+Cs6LpnI3gBayxwTy8QVNKjboI2t0P 0s+IBLcEU6oIX+4c2SN6dcFkBY0eY42q8EqqQuE= X-Google-Smtp-Source: ABdhPJy9nCE4wcX9jikR0i2kI/EK/tfRsxbU2ZACT1fCuK63zw4leq9Ayd+83Tn2Lm6h6kyV23piIE3gFCQt95mshU4= X-Received: by 2002:a9d:4808:: with SMTP id c8mr7121674otf.194.1606499267769; Fri, 27 Nov 2020 09:47:47 -0800 (PST) MIME-Version: 1.0 References: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> <314553E7-B3D9-43B4-B775-31482C5035C6@vigilsec.com> In-Reply-To: <314553E7-B3D9-43B4-B775-31482C5035C6@vigilsec.com> From: Jonathan Hammell Date: Fri, 27 Nov 2020 12:47:36 -0500 Message-ID: To: Russ Housley Cc: "Brockhaus, Hendrik" , LAMPS , "steffen.fries@siemens.com" , "hans.aschauer@siemens.com" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 17:47:50 -0000 Russ: > > However, I'm concerned about the ASN.1 for PBMParameter Section 4.4 of > > RFC 4211 for the following reasons. If one wanted to use scrypt (RFC > > 7914) for the owf, there is duplication of the salt parameter and the > > iterationCount in PBMParameter would no longer be relevant. One might > > even want to use Argon2 (draft-irtf-cfrg-argon2), but unfortunately > > there is no ASN.1 module in that I-D to specify parameterization. I > > realize that backwards compatibility needs to be maintained for > > PBMParameter so those parameters cannot be made OPTIONAL, but perhaps > > some guidance like the following should be added? > > > > "If a salt value is specified in the AlgorithmIdentifier parameters > > for owf (such as in [RFC7914]), the salt value in PBMParameter MUST > > NOT be used and it SHOULD be the zero-length octet string. Similarly, > > if the mechanism specified in owf has its own cost parameter for > > deriving a key (such as in [RFC7914]), then the iterationCount value > > in PBMParameter MUST NOT be used and it SHOULD be set to 0." > > I do not think I agree. If you want to use one of these other constructions, wouldn't completely replace id-PasswordBasedMAC? You would not be able to just replace id-PasswordBasedMAC with id-scrypt since you need the specification for the MAC construction to perform the proof of possession. However, you are right, it might be best to use a new OID and define a new parameters structure to use a MAC with one of these alternative PBKDF mechanisms. Best regards, Jonathan From nobody Fri Nov 27 12:09:58 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684143A0E70 for ; Fri, 27 Nov 2020 12:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYXCLuI22kKX for ; Fri, 27 Nov 2020 12:09:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98BC3A0E6F for ; Fri, 27 Nov 2020 12:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0F34A300BA6 for ; Fri, 27 Nov 2020 15:09:51 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qKO61YzEOx-d for ; Fri, 27 Nov 2020 15:09:49 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 29A90300670; Fri, 27 Nov 2020 15:09:49 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Fri, 27 Nov 2020 15:09:50 -0500 Cc: LAMPS Content-Transfer-Encoding: quoted-printable Message-Id: <3784F36B-563A-486C-B073-EB2E302E0068@vigilsec.com> References: <86E7B55E-986C-42C1-8E02-20FB70C2F022@vigilsec.com> <314553E7-B3D9-43B4-B775-31482C5035C6@vigilsec.com> To: Jonathan Hammell X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [lamps] draft-housley-lamps-crmf-update-algs - proposal on adding text regarding iterationCount and pwd quality X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 20:09:56 -0000 Jonathan: >>> However, I'm concerned about the ASN.1 for PBMParameter Section 4.4 = of >>> RFC 4211 for the following reasons. If one wanted to use scrypt = (RFC >>> 7914) for the owf, there is duplication of the salt parameter and = the >>> iterationCount in PBMParameter would no longer be relevant. One = might >>> even want to use Argon2 (draft-irtf-cfrg-argon2), but unfortunately >>> there is no ASN.1 module in that I-D to specify parameterization. I >>> realize that backwards compatibility needs to be maintained for >>> PBMParameter so those parameters cannot be made OPTIONAL, but = perhaps >>> some guidance like the following should be added? >>>=20 >>> "If a salt value is specified in the AlgorithmIdentifier parameters >>> for owf (such as in [RFC7914]), the salt value in PBMParameter MUST >>> NOT be used and it SHOULD be the zero-length octet string. = Similarly, >>> if the mechanism specified in owf has its own cost parameter for >>> deriving a key (such as in [RFC7914]), then the iterationCount value >>> in PBMParameter MUST NOT be used and it SHOULD be set to 0." >>=20 >> I do not think I agree. If you want to use one of these other = constructions, wouldn't completely replace id-PasswordBasedMAC? >=20 > You would not be able to just replace id-PasswordBasedMAC with > id-scrypt since you need the specification for the MAC construction to > perform the proof of possession. However, you are right, it might be > best to use a new OID and define a new parameters structure to use a > MAC with one of these alternative PBKDF mechanisms. It seems like a two page document + boilerplate. Russ= From nobody Sun Nov 29 23:26:45 2020 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE513A10C7 for ; Sun, 29 Nov 2020 23:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=BhpFpLuS; dkim=pass (1024-bit key) header.d=primekey.com header.b=wb/BbjDy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toMFVuOaM7Yp for ; Sun, 29 Nov 2020 23:26:40 -0800 (PST) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F6C3A10C4 for ; Sun, 29 Nov 2020 23:26:39 -0800 (PST) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 0E3E46AA4F8D; Mon, 30 Nov 2020 08:26:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1606721197; bh=nCYpFmTDb1St59aESjy3E+D52Nzo/8nFHbpjT228m0k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BhpFpLuS8aBv41WDS/l9ylDlCZUBzhEF3UvD5dA9G2LUuSR/rKx/zItUHueqr+u8/ 34q/LLNiJyc8dPKL2Tciz+wDBYvpim79pSf/Y9FYwdSEgZLc+GhTdld9vL9feqEWmK 6q9d08YweDZq1AGoW0l6XZJl2DN+o6/DuQT86Ays= Received: from [10.11.0.10] (unknown [10.11.0.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id E06FE6AA4F89; Mon, 30 Nov 2020 08:26:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1606721196; bh=nCYpFmTDb1St59aESjy3E+D52Nzo/8nFHbpjT228m0k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wb/BbjDyPFF//V2ueysR/Df8wrZSn2AZj41tED4OulIurDAyOoSaKOR/p8czFcci2 495pyEbzykzmxuuj/jd9TImDovpti1eLbO2UsG9JXAVqUgEOHwzF+/POLRQgdxivLZ DP4GxeUjACXytFanXgexMr9oKzXnkWF/Gvap+M+Y= To: Rene Struik , spasm@ietf.org References: <1b53e44d-b0fa-88cd-63dc-2d3d149fbc52@primekey.com> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <19b0a60f-23df-beb2-4d88-87bd54372d0c@primekey.com> Date: Mon, 30 Nov 2020 08:26:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] supporting ECDSA25519, i.e., ECDSA/SHA256 with Curve25519 under the hood (was: Re: LAMPS Minutes for IETF 109) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 07:26:45 -0000 Hi, I'm glad to give more information. Luckily PKCS#11 is also an open standard, under Oasis. https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html Background --- PKCS#11 is probably the most common API to interface, in a standards interoperable way, with crypto hardware such as HSMs, smart cards, USB tokens and the like. It is a C API, ageing in technology, but it has served us well for the last 25 years. I'll dare to say that despite it's shortcomings it has served us very well, and i one of the few technologies that have delivered on the promise "write once, run everywhere". Writing C, Java, Python, C# code using PKCS#11 against one crypto module, it is likely to work with another from another vendor only with proper configuration of the vendor driver (usually a config file to tell the PKCS#11 driver, .so lib file, where the module is, and some vendor specific configuration). It is what many (most) clients use to communicate with hardware tokens. FOr example if you want to use a smart card for TLS client authentication, FireFox, Chrome and Safari uses PKCS#11 to talk to your smart card. If you want to sign an email with S/MIME your email client (for example Thunderbird) uses PKCS#11 to talk to the smart card or USB-token. If you issue certificates or create remote server side signatures (eIDAS) the server (CA or signing server) user PKCS#11 to talk to the HSM. Ed25519 specifics ----- PKCS#11 uses mechanisms (long values. In P11v3 you can generate an Ed25519 key pair. https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061187 Ed25519 is defined here in the standard as RFC 8032 and RFC 8410. Typically, in P11v3, you provide the OID of Ed25519, RFC 8410. Many vendors implemented this before the final version of P11v3 was out, and then used names such as curve25519 or Ed25519 to the key pair generation function. Resulting in if's in the code doing key generation (no write once run everywhere any more). The same with signatures: https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061191 The CKM_EDDSA is a constant (0x00001057L in P11v3). But vendors implementing it before, and that haven't moved to P11v3 yet use their own "vendor defined" mechanisms, for example (0x80000000L + 0xC03L). Some more if's in the code when signing data. Conclusion: ----- So maybe I take my hesitation back a little bit. - Starting to use a new algorithm with hardware devices is a PITA if standardization hasn't gone the complete mile. Usually I see it go a bit like this: - IETF standardizes the algorithm itself, for usage in RFCs - IETF standardizes OIDs - IETF standardizes usage in other RFCs (Certificates, S/MIME, TLS, etc) - Oasis takes on and standardizes usage in PKCS#11 With take it back I mean that a prerequisite for it getting into PKCS#11 is that the needed RFCs exist. So if it should be used, it must be standardized in RFCs first. Then it may take years before it's actually used, but that's another story. New algorithms take a long time to get into P11, but variations (new hash algorithms, new EC curves but the same signature math) are quicker and are put into point updates of P11. The same goes for PQC algorithms btw. Cheers, Tomas On 2020-11-27 15:41, Rene Struik wrote: > Hi Tomas: > > Thanks for your note. It would help to understand somewhat more your > "custom encoding" remark. (I do think this would be enlightening in > general, since HW insights are not widely available within IETF). > > Also, I would be curious which version of Ed25519 is gaining support > (there are many), since the deterministic scheme specified in RFC 8032 > has come under criticism [1]. In fact, this motivated my suggestion to > use ECDSA25519 and to provide something that at least has been known to > work effectively (and without buffering issues). > > Could you provide a pointer to the PKCS11v3 specification that provides > all technical details? (or, is this behind a paywall)? > > Ref: [1] > https://tools.ietf.org/html/draft-mattsson-cfrg-det-sigs-with-noise-02 > > On 2020-11-27 1:30 a.m., Tomas Gustavsson wrote: >> My two cents. >> >> Working with hardware security modules it's a bit of a pain as it is >> with EdDSA. As PKCS#11 supports it in PKCS#11v3 which is not yet widely >> available in implementations you have to do custom coding for each >> hardware module. Adding more options for users, that are not broadly >> available makes it confusing and hard to make (cost effective) choices. >> >> Therefore I would not like to add algorithms that have not yet gained >> wide support. >> >> We also see that Ed25519 is gaining support (P11v3 is making inroads), >> making that logical to add. >> >> I also have not used DSA, or heard any requests for it, for about 10 >> years or so. I support dropping it. >> >> Best regards, >> Tomas >> >> On 2020-11-26 21:57, Rene Struik wrote: >>> Dear colleagues: >>> >>> Do you think supporting ECDSA25519 would make sense as well? >>> >>> This is well-defined and non-deterministic and also can use existing >>> Curve25519 ladders under the hood (see [1]) as well as existing >>> generic hardware supporting short-Weierstrass curves (see [2]). >>> >>> Due to the PKIX/CMS OID requested during IETF Last-Call on lwig-curve >>> draft [3], it seems this could just be used without further ado. >>> >>> Best regards, Rene >>> >>> Ref: >>> [1] >>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-14#section-4.3 >>> >>> [2] >>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations#section-6 >>> >>> [3] >>> https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations >>> >>> >>> == >>> >>> [excerpt of draft minutes] >>> >>> Current signature algorithms include DSA, RSA, ECDSA with SHA-2 and >>> RSASSA-PSS. Russ mentioned that signing with Ed25519 (uses >>> Curve25519) is gaining support.  Russ (and several in chat) suggested >>> dropping DSA. No objections. >>> >>> >>> >>> >>> On 2020-11-25 5:43 p.m., Russ Housley wrote: >>>> https://datatracker.ietf.org/meeting/109/materials/minutes-109-lamps-00 >>>> >>>> Please send a note is you see anything that needs to be corrected. >>>> >>>> Thanks Jonathan.  Your notes were excellent. >>>> >>>> Russ >>>> >>>> _______________________________________________ >>>> Spasm mailing list >>>> Spasm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spasm >>> >>> --  >>> email: rstruik.ext@gmail.com | Skype: rstruik >>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867 >>> >>> >>> _______________________________________________ >>> 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 > >