From nobody Sun Mar 1 19:39: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 54AE13A098C for ; Sun, 1 Mar 2020 19:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8ICOcJ5qEtr for ; Sun, 1 Mar 2020 19:39:16 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 47E783A09DE for ; Sun, 1 Mar 2020 19:39:15 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id 8bQCj6TYhlbu38bvHj5Mmz; Mon, 02 Mar 2020 03:39:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1583120355; bh=Ahk8yRFjS9D3itAiuPaBKxoFVbzuc74MeTUaAvsfreo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=ZM3Lh/wS7WHmV2TSWcV/3vgPdK+4BkC1OF1moSO2twteCvKad9aZTz71XWAkCAwtL B4vW2tCdY2t+n6DgdCVRprWgTBV1tLpF7UXGS6sw6z6WzlDYJiSlx1OmwjZf3BojdJ jPzc/oPTC8u2wXaG8rNEFYh45mCg+fedmqk2bJuWiBm4GO2WH4JCfoe8jHEejsamS7 YNlswJ0t64HnquSAUp2q379SSRcW3Nf7nli6Nxx7m7qJ/7LcUaE5DxiXZeVOeaeeAy Ep2tQyJgJ91SHZJC6nMyaj5zo1uq+Lrq34SG4luWJf/SnehOWfr4MmfL15C+orcRAu coodgY2xDdmnA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id 8bvFjlFCccAr98bvGj6773; Mon, 02 Mar 2020 03:39:14 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0223dBYh007934; Sun, 1 Mar 2020 22:39:11 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0223dA6B007924; Sun, 1 Mar 2020 22:39:10 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Turner Cc: gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org In-Reply-To: <6888D55C-5A3D-4C8E-AF6C-ED96235A1691@sn3rd.com> (sean@sn3rd.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 01 Mar 2020 22:39:10 -0500 Message-ID: <87blpfctnl.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-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: Mon, 02 Mar 2020 03:39:19 -0000 Sean Turner writes: > BTW - I spun a new version to make the changes I noted early (at the > request of Roman) I will read the new version and go from there. I realize that this I-D is just a modification of a previous RFC and as such there isn't a requirement that it be fully comprehensible on its own. However, I'm sensitive to terminology, and I want to ensure that even if reading the document alone does not fully inform the reader, it should not cause them to believe incorrect things because the terminology does not properly reflect the reality. Dale From nobody Sun Mar 1 20:00: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 D81903A0A6D for ; Sun, 1 Mar 2020 20:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZGzNvIxPY-w for ; Sun, 1 Mar 2020 20:00:31 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 73A8C3A0AA4 for ; Sun, 1 Mar 2020 20:00:31 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id 8c4rjjiL1QWuC8cFqjW5KK; Mon, 02 Mar 2020 04:00:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1583121630; bh=gU7yxbZkDoh4d73aG8tCA5rO3nPYMkpWT/zVhcTE+KA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=mRjn3kfAi4FMjkzFKWvn450xjYt1hoA5Wz35T69XIpkU0NLxzE4Flyf+/LLHXWNTM GrZ9xDU/uE71Y1fXppY25h89wY8Xqyxc6HL6JZ43Frz9QJvrQEq8ZCOIHivXhNr18a RWE5UEulCkmqVLKSjSIAiN/j+K43pqomXzJlZZJPWXS7ipuEMzXenjZ+BhdG6DXJBN 6azTUu80bfeVbCT6c0Vx/cpoJkNpVueGemT3hJZr5gvCso5lqwjGPeoxCwXIzkCVaH oTiI2XsM7JoKK7qXC8w1Q2Nkrw6uZYBBlBPGRj26Sq/acjdgZ+i2sQGSy29ruOLdGk CDmZaWUrblGJw== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id 8cFpjv8ns7vgv8cFpj9B8u; Mon, 02 Mar 2020 04:00:30 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 02240RhD010191; Sun, 1 Mar 2020 23:00:27 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 02240QUW010181; Sun, 1 Mar 2020 23:00:26 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Turner Cc: gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org In-Reply-To: <6888D55C-5A3D-4C8E-AF6C-ED96235A1691@sn3rd.com> (sean@sn3rd.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 01 Mar 2020 23:00:26 -0500 Message-ID: <878skjcso5.fsf@hobgoblin.ariadne.com> Archived-At: Subject: [lamps] draft-ietf-lamps-5480-ku-clarifications-01 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 Mar 2020 04:00:36 -0000 Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points occur to me: 1. Introduction This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms. I think it would be more accurate to say something like "neither ... are set in certificates that specify key agreement algorithms" -- usage bits are logically a component of a certificate rather than a feature of an algorithm. But it's unclear to me whether id-ecPublicKey is only used in key agreement certificates. RFC 5480 states that if the cert uses id-ecDH or id-ecMQV and provides keyUsage, then keyAgreement must be set. So it's clear that certs with id-ecDH or id-ecMQV are key agreement certs. But RFC 5480 says that if the cert lists id-ecPublicKey, then keyAgreement is optional. That suggests to me that some certs can use id-ecPublicKey without being key agreement certs. In turn, section 1 of this I-D suggests the I-D is not intended to apply to those certs, but section 3 seems to apply to them anyway. To try to distill it to one sentence: Can id-ecPublicKey appear in certs that are not for key agreement, and if so, are keyEncipherment and dataEncipherment allowed in the keyUsage of those certs? 3. Updates to Section 3 If the keyUsage extension is present in a certificate that indicates in SubjectPublicKeyInfo, then following values MUST NOT be present: ---^ Is "id-ecPublicKey" missing here? If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values also MUST NOT be present: Is it a fact that all certificates with these three algorithms are certificates for key agreement? If so, it would be nice to state that either in section 3 or section 1, to show how section 3 is connected with "for key agreement algorithms" in section 1. Otherwise, the connection between the two requires information that is stated elsewhere. Dale From nobody Mon Mar 2 07:20: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 5B3B23A08C4 for ; Mon, 2 Mar 2020 07:20: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, 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 rxC5g0UfjZk5 for ; Mon, 2 Mar 2020 07:20:54 -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 EEE6E3A08C2 for ; Mon, 2 Mar 2020 07:20:53 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id d15so11935753iog.3 for ; Mon, 02 Mar 2020 07:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zksQGhKQZPy+LN8lXXlkvqGMpSEAoR326A0HuABwOlI=; b=g1naztBpQ//m03TSWp5sirPKoZAwI2lLb+Krtm9r34K9bJyd+snOIyaGbupjptzZyB 7KgOSl3mHe9HW45Nbe8tJimDay7HqkUf3+cun1tv4RClIjnoqhzZGzEt52Mne57GWzbx Q7hXGsYGmDF66HGtoyzy60op/u+vFxfrNj+pUNE1rnPHJElSTNBk5ZzCS7VVz/rHbjzj V+i5D/+oaE2m6170d3qrmYIUdUIprlkQ9zeSzHyU8lJ1Y1bgeHXg/12kdv6ZwxJXqQJg fLFvo3pedMgUgw4HzFkw/0oAEtID5dFvCF9TKsNgo44UEZqDGtbtxFlWh54RY/rCYMZI erhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zksQGhKQZPy+LN8lXXlkvqGMpSEAoR326A0HuABwOlI=; b=KzPlDnqEe5j6bAM8RaoTV9oUVTB4gOOpm5/7fHkM22r1J3s0h1Jj3DvjiJnWmhOmOw 4X94f8eRa9YYBZuuoOkuPL/hrpQG/+oCqrFZhJoj+LbH0HVRkSusE0QwlzSZ3Jf+2yzA a7i5Xhk8LxV4DsnWXO7CkKkOz8c1l8jeV68/fJ5hc0wEIsvCcthswdJoil2o/SYvWgVc 6IBYjBiZkImRr/E4ovPL2PnDsglEkg67zUVNDbB6lSqVD7PaviAXNSDxx2VJhfsG7KB5 z1i46FI5h7FtqWrCsUJQqJOH9Bdyx9ASxZSo+o6/OAKVgMDOmyx7dKI6kRTSJh/EJ15C t1Hg== X-Gm-Message-State: ANhLgQ2VwhaR435WuBy6/Gak0Gw2v1FPvLn4Jv2nSwpE3XXXPiDky1Dx rHDtkGevFA7JxA2q/PNOAm1rCOevWyQt2I9HClNweT/4 X-Google-Smtp-Source: ADFU+vuzoM01g3AtgwoqMAanbB/m3Ol4ohsSRaRtLSKqoIegf1Kh+0/jTBUSiOdDYPjQbxME6HkazV7rZfjhwVzVlFk= X-Received: by 2002:a02:7317:: with SMTP id y23mr4809824jab.85.1583162452048; Mon, 02 Mar 2020 07:20:52 -0800 (PST) MIME-Version: 1.0 From: Mohit Sahni Date: Mon, 2 Mar 2020 07:20:42 -0800 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary="000000000000938997059fe0bb41" Archived-At: Subject: [lamps] RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 15:20:55 -0000 --000000000000938997059fe0bb41 Content-Type: text/plain; charset="UTF-8" Hi All, I started a thread about the issues with the OCSP Nonce extension which was missing the maximum length for the Nonce field in the extension and could create potential security issues with the OCSP responder following RFC 6960. https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ Based on valuable feedback that I got from the members here, I have written a draft limiting the length of Nonce extension between 1-32 bytes. Here is the link to the draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. Please let me know what you think. Thanks Mohit Sahni --000000000000938997059fe0bb41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
I started a thread about the issues with the O= CSP Nonce extension which=C2=A0was missing the maximum=C2=A0length for the = Nonce field in the extension and could create=C2=A0potential=C2=A0security = issues with the OCSP responder following RFC 6960.

Based on valuable=C2=A0feedback that I got from= the members here, I have written a draft limiting the length of Nonce exte= nsion=C2=A0between 1-32 bytes.=C2=A0 Here is the link to the draft=C2=A0https://datatracker.ietf.org/doc/draft-msa= hni-lamps-ocsp-nonce/?include_text=3D1. Please let me know=C2=A0what yo= u think.

Thanks
Mohit Sahni
--000000000000938997059fe0bb41-- From nobody Mon Mar 2 07:45: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 8835D3A0957 for ; Mon, 2 Mar 2020 07:45:23 -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=primekey.com header.b=UH20A6GU; dkim=pass (1024-bit key) header.d=primekey.com header.b=UH20A6GU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4NVaNSStyHZ for ; Mon, 2 Mar 2020 07:45:20 -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 31C2D3A0959 for ; Mon, 2 Mar 2020 07:45:20 -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 4C9E66AA009C for ; Mon, 2 Mar 2020 16:45:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583163905; bh=HzhBXIp+KwwFMVMrsd9q57RXtcq+t/vonTxjPc4Wldo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UH20A6GUBNyjzWuXYSp54i9ZIHu5HYorePwCTXHZINxmSz1jCPVzM6ejzHjWUb4+2 gBUsLMr0l6qMkQTJ2U+XTT/peupEPWkj5ubFI/41NB9q1peO1gvSWTo6LqT5ofNpBC 34a2lBw6U6cgioj39x+vp1TygxzhalFNdl5Y9Y5A= Received: from [172.20.5.87] (64-71-28-71.static.wiline.com [64.71.28.71]) (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 C65FA6AA0099 for ; Mon, 2 Mar 2020 16:45:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583163905; bh=HzhBXIp+KwwFMVMrsd9q57RXtcq+t/vonTxjPc4Wldo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UH20A6GUBNyjzWuXYSp54i9ZIHu5HYorePwCTXHZINxmSz1jCPVzM6ejzHjWUb4+2 gBUsLMr0l6qMkQTJ2U+XTT/peupEPWkj5ubFI/41NB9q1peO1gvSWTo6LqT5ofNpBC 34a2lBw6U6cgioj39x+vp1TygxzhalFNdl5Y9Y5A= 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: <94992241-8b6f-7278-4ca3-74a8925be91e@primekey.com> Date: Mon, 2 Mar 2020 07:45:15 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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] RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 15:45:24 -0000 Thanks for drafting this. Perhaps security considerations should mention that the nonce should contain enough cryptographically strong randomness to prevent easy guessing of the nonce (hence to fulfill the purpose)? Regards, Tomas On 2020-03-02 07:20, Mohit Sahni wrote: > Hi All, > I started a thread about the issues with the OCSP Nonce extension > which was missing the maximum length for the Nonce field in the > extension and could create potential security issues with the OCSP > responder following RFC 6960. > https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ > > Based on valuable feedback that I got from the members here, I have > written a draft limiting the length of Nonce extension between 1-32 > bytes.  Here is the link to the > draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. > Please let me know what you think. > > Thanks > Mohit Sahni > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon Mar 2 07: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 CECDE3A095C for ; Mon, 2 Mar 2020 07:47:23 -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 zEeaAIf-NFyv for ; Mon, 2 Mar 2020 07:47:22 -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 538983A095E for ; Mon, 2 Mar 2020 07:47:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 02CBE300B45 for ; Mon, 2 Mar 2020 10:47: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 8qe9-pVlAXND for ; Mon, 2 Mar 2020 10:47:17 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id C434D300A2E; Mon, 2 Mar 2020 10:47:17 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DCD18D43-BCBE-4B5A-A027-900CC60D7F33" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 2 Mar 2020 10:47:19 -0500 In-Reply-To: Cc: spasm@ietf.org To: Mohit Sahni References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 15:47:24 -0000 --Apple-Mail=_DCD18D43-BCBE-4B5A-A027-900CC60D7F33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A nonce of 1 octet does not really provide the intended protection. = Maybe we more could be said in the Security Considerations about the = minimum size. Also, why is Section 3.1 indented? Russ > On Mar 2, 2020, at 10:20 AM, Mohit Sahni wrote: >=20 > Hi All, > I started a thread about the issues with the OCSP Nonce extension = which was missing the maximum length for the Nonce field in the = extension and could create potential security issues with the OCSP = responder following RFC 6960. > = https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ = = >=20 > Based on valuable feedback that I got from the members here, I have = written a draft limiting the length of Nonce extension between 1-32 = bytes. Here is the link to the draft = https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_te= xt=3D1 = . Please let me know what you think. >=20 > Thanks > Mohit Sahni --Apple-Mail=_DCD18D43-BCBE-4B5A-A027-900CC60D7F33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii A = nonce of 1 octet does not really provide the intended protection. =  Maybe we more could be said in the Security Considerations about = the minimum size.  Also, why is Section 3.1 indented?

Russ


On Mar 2, 2020, at 10:20 AM, Mohit Sahni = <mohit06jan@gmail.com> wrote:

Hi All,
I started a thread about the issues = with the OCSP Nonce extension which was missing the = maximum length for the Nonce field in the extension and could = create potential security issues with the OCSP responder = following RFC 6960.
https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmb= cULfgBSA/

Based on valuable feedback that I = got from the members here, I have written a draft limiting the length of = Nonce extension between 1-32 bytes.  Here is the link to the = draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/= ?include_text=3D1. Please let me know what you think.

Thanks
Mohit = Sahni

= --Apple-Mail=_DCD18D43-BCBE-4B5A-A027-900CC60D7F33-- From nobody Mon Mar 2 09:10:30 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 BEA893A0C82; Mon, 2 Mar 2020 09:10:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158316902472.27462.8228261234382311611@ietfa.amsl.com> Date: Mon, 02 Mar 2020 09:10:24 -0800 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-5480-ku-clarifications-02: (with COMMENT) 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 Mar 2020 17:10:25 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-5480-ku-clarifications-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm somewhat amenable to the genart reviewer's concerns that we are implicitly asserting restrictions in RFC 5480 usage by describing the algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 does not seem to use that terminology to refer to id-ecPublicKey. Section 1 Cryptography. As part of these semantics, it defines what combinations are permissible for the values of the key usage extensions [RFC5280]. [RFC5480] specifies 7 of the 9 values; it nit: IMO, "key usage extensions" would mean both keyUsage and extendedKeyUsage, but this document considers only the identified bits in the original keyUsage extension, and thus the singular "extension" would be more appropriate. Section 4 What are the considerations that apply to implementations that follow RFC 5480 but not this document, e.g., existing implementations that allow keyEncipherment and/or dataEncipherment? Specifically, if we are forbidding their usage, is it because there are vulnerabilities to doing so? It seems like we should mention them here. From nobody Mon Mar 2 12:08: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 C2ADA3A1086 for ; Mon, 2 Mar 2020 12:08:51 -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 wWNHEW0-b-eZ for ; Mon, 2 Mar 2020 12:08:49 -0800 (PST) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 9361B3A1052 for ; Mon, 2 Mar 2020 12:08:49 -0800 (PST) Received: by mail-io1-xd43.google.com with SMTP id q128so805440iof.9 for ; Mon, 02 Mar 2020 12:08:49 -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=hgCRlKs6o3v6NzOjvI5F6eSELujextCY4jNGszzguY4=; b=kF45QqPSjl/8OWsRdFqYk7M3OJ4w5LHCy9G9vPZu7cCxgrB1vVuiUOSjMsi+rGzFtV 6lLsXacj1uKMyYFc+7YS3EfnMl/nftObUK8sjj09rzf9eZdPbow5AEwQ0t2gYhQDgomr Y8Glr70QdjckyCll9kwGATrQ8Sca+DPZDxFadkUsjeXPN6rZKCThAoJYCXs2Gvhdd8UH aQQBd644RERFZ10LwRLeOBvKYyz9QaLar+FbXEBvuygNfOB8VNUKNDUp+BuuSLfTGZ72 8gsR/WHfZW9psHrd3wrZez9YfsxaSh3fh6f7oJQmJc+9G9lrgF4zAnZ/g1QMuKtKINo7 eNsg== 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=hgCRlKs6o3v6NzOjvI5F6eSELujextCY4jNGszzguY4=; b=Mn9dV1b0vKAfatcDpRlVfVOquwR/xzlnAZMOTX33iOfG36foxW9+ien9PJUFiBjUvF Mn2LLPjXep2SAgNC6zUP50XLU8QB7CAvuMSOikjQ+cEMpMi5KXnbMgDYvYR7g2h3Ix3S gWqgTLar4gcTnIqyeY/iGU9P+HQbLIvzpggp+yWVoMCCBr6bXkKTeoa6QILPPzaM9LNd yoaHtfPsuuSSqj4XEltm+I3JWTBR4ECqyxLHWlYjq0DccGxI5742Euz+/8Ydusy6jZrg JHQJT/YP11SVKGSU/iGoc8XB9A5w+7QDhNp20efayvd/pR6XJqCAwujG6plK2u+ZNHv2 pSJw== X-Gm-Message-State: ANhLgQ3zFl5JDtpKY3VDWjzEpMIq118VZZUJj3RNpEji4hVDhI2qZn3R VityWr2oLS7Ydk4UZAmm+WtEOkoVg66E5EayOFg= X-Google-Smtp-Source: ADFU+vvqBI6ZqPgdvw2vjSzWrviS1MGDUs6Uf0XLb2On87gt/GK4jovZDS4g59uigfQ9Xyvmmuza5yaTMisLO1fVJFc= X-Received: by 2002:a6b:7c4d:: with SMTP id b13mr1155311ioq.46.1583179728730; Mon, 02 Mar 2020 12:08:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Mon, 2 Mar 2020 12:08:38 -0800 Message-ID: To: Russ Housley , tomas.gustavsson@primekey.com Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="00000000000058c03b059fe4c14d" Archived-At: Subject: Re: [lamps] RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 20:08:52 -0000 --00000000000058c03b059fe4c14d Content-Type: text/plain; charset="UTF-8" @Thomas: Using "cryptographically strong randomness" to generate nonce is a good suggestion and I also thought about it while writing the draft. The purpose of nonce in OCSP request/response is to detect a replay. As long as a client receives the same nonce in response as what they sent in request and the signature in OCSP response can be verified and trusted they should able to detect a replay attack. In my opinion client should not reuse the same nonce in multiple requests, we can either mandate client to use different nonce for each request made in a specified window of time or we can mandate client to use "cryptographically strong randomness" to get a random nonce. Please suggest which approach is better in your opinion. @Russ, sure, I am taking a note of adding security consideration about "using 1 octet nonce". Regarding the section 3.1, I added it to highlight risks created by the recommendation made in RFC5019, which suggests that if server does not send a nonce in OCSP response then client should not reject the response just because nonce is missing( https://tools.ietf.org/html/rfc5019#section-4). I know its out of context here but still wanted to re-enforce that there is a risk of replay attack if client chose to accept the response with the missing nonce. Thanks Mohit On Mon, Mar 2, 2020 at 7:47 AM Russ Housley wrote: > A nonce of 1 octet does not really provide the intended protection. Maybe > we more could be said in the Security Considerations about the minimum > size. Also, why is Section 3.1 indented? > > Russ > > > On Mar 2, 2020, at 10:20 AM, Mohit Sahni wrote: > > Hi All, > I started a thread about the issues with the OCSP Nonce extension > which was missing the maximum length for the Nonce field in the extension > and could create potential security issues with the OCSP responder > following RFC 6960. > https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ > > Based on valuable feedback that I got from the members here, I have > written a draft limiting the length of Nonce extension between 1-32 bytes. > Here is the link to the draft > https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. > Please let me know what you think. > > Thanks > Mohit Sahni > > > --00000000000058c03b059fe4c14d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Thomas:=C2=A0
Using "cryptographically strong ra= ndomness" to generate nonce is a good suggestion and I also thought ab= out it while writing the draft. The purpose of nonce in OCSP request/respon= se is to detect a replay. As long as a client receives the same nonce in re= sponse as what they sent in request and the signature in OCSP response can= be verified and trusted they should able to detect a replay attack. In my = opinion client should not reuse=C2=A0the same nonce in multiple requests, w= e can either mandate client to use different nonce for each request made in= a specified window of time or we can mandate client to use "cryptogra= phically strong randomness" to get a random nonce. Please suggest whic= h approach=C2=A0is better in your=C2=A0opinion.=C2=A0

@R= uss, sure, I am taking a note of adding security consideration about "= using 1 octet nonce".=C2=A0 Regarding the section 3.1, I added it to h= ighlight risks created by the recommendation made in=C2=A0RFC5019, which su= ggests that if server does not send a nonce in OCSP response then client sh= ould not reject the response just because nonce is missing(https://tools.ietf.org/html/rfc50= 19#section-4). I know its out of context here but still wanted to re-en= force that there is a risk of replay attack if client chose to accept the r= esponse with the missing nonce.

Thanks
=
Mohit=C2=A0

On Mon, Mar 2, 2020 at 7:47 AM= Russ Housley <housley@vigilsec.com> wrote:
A nonce of 1 octet does not really provide the in= tended protection.=C2=A0 Maybe we more could be said in the Security Consid= erations about the minimum size.=C2=A0 Also, why is Section 3.1 indented?
Russ


On Mar 2, 2020, at 10:20 AM, Mohit Sahni <mohit06jan@gmail.com> wrote:

=
Hi All,
I started a thread about the issues with = the OCSP Nonce extension which=C2=A0was missing the maximum=C2=A0length for= the Nonce field in the extension and could create=C2=A0potential=C2=A0secu= rity issues with the OCSP responder following RFC 6960.

Based on valuable=C2=A0= feedback that I got from the members here, I have written a draft limiting = the length of Nonce extension=C2=A0between 1-32 bytes.=C2=A0 Here is the li= nk to the draft=C2=A0https://datatracke= r.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=3D1. Please = let me know=C2=A0what you think.

Thanks
<= div>Mohit Sahni

--00000000000058c03b059fe4c14d-- From nobody Mon Mar 2 12:29: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 3C45B3A0BD1 for ; Mon, 2 Mar 2020 12:29:24 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=entrustdatacardcorp.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 wJVjK6Q1OAfo for ; Mon, 2 Mar 2020 12:29:22 -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 66FEC3A07A9 for ; Mon, 2 Mar 2020 12:29:22 -0800 (PST) IronPort-SDR: KMQMGEeZftRZN7J+xTYCni6yoYCcaNGeqtDu7snz5cmeVy4gEf0lFYrCuhIJdyDjbPeQhgA8UG rV9NpiU0ndmA== X-IronPort-AV: E=Sophos;i="5.70,508,1574143200"; d="scan'208";a="68467198" Received: from pmspex03.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.50]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 02 Mar 2020 14:29:21 -0600 Received: from PMSPEX03.corporate.datacard.com (192.168.211.50) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 14:29:21 -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; Mon, 2 Mar 2020 14:29:21 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TCjMcL0z2H69A1SLIXYUgT0DZG/OMaPxSHgG8DP3u4NQPlCPwWjbqwtj4bRxzNVMZDXMbXkkn7sHtWlc18vEu6j4dS+2wsyNJ1iA+HCUVamIi2yvnWGkPJVXpchEouqpPa+MsCASlgZdjJrLMifyfobmE8a8RBAPzt+iIccsgaF0siGx8uzRqC/QcPIoSDRBryu7gZs5tyr5+x0G34Ti42TbsS4YbBaLoXAPPkjtdpMSLcA1FEXN/xBEpnP6BFv9pw23OQ7korst42MFN/Iv/ZAzAD/pYUVn0OE55PC8wcxS0ZxnaTPkctK0MfAHjgjqAIStaP/aQBEvNfbyK62h2w== 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=hJ8mvS/1DyFINFdV5DGKWGAIZkjTyMixjcrNp1jVWVw=; b=Ui7X/BIh7Zsvvg+PAEqHA854I6fakKf3/UtC1H8n9Q+xCANZUA/oa3hPAZAtoFCBUb8nmbuVpLqL7bVrHgusQeXoTr7FpJBwb281fQPKthks13SyX0xcLZuuV2VGDLRrTC3S4GZNbwCgwy5NouLgeubH9pXPYL5n/6u7rx/S2gORvpB7PKbDXKfOliTgIvzM5ihR8Djak4uirQOzGzMS6HObdYysF+dWQm5L+CvMlmFXa1GAjbCbC6eaFeqk0OQ+XdGrXNZ+6EFwDnzOR4UwNCBxFwOVTiWXBau1uKbVB+2NqFkdjCpqT00J7qy8RQjEtv1Ngr30EXB0ptfAtdxILg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hJ8mvS/1DyFINFdV5DGKWGAIZkjTyMixjcrNp1jVWVw=; b=tIgRAMXAYiWo3/4HVm269tq3IdDtO5ykK4AQAA5fIojeB0ipGr8aj3CJOa69rXABbhjG0RjU0t1QAHdbx5sXbuICvqVrDOJMQtxP3+Ie0G8EyTBHKlYj+F+bg0X99ykQXtyuCrlFYnC9nAxYrfRXAQic1CNMR1vnBV3beJp6pAE= Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB3420.namprd11.prod.outlook.com (2603:10b6:5:69::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Mon, 2 Mar 2020 20:29:20 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::942:9c0:9497:beea]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::942:9c0:9497:beea%3]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 20:29:20 +0000 From: Mike Ounsworth To: Mohit Sahni , Russ Housley , "tomas.gustavsson@primekey.com" CC: "spasm@ietf.org" Thread-Topic: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce extension Thread-Index: AQHV8KniveapMzyinEyvqssbNJgiXqg1u2QAgAACz5A= Date: Mon, 2 Mar 2020 20:29:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f90bcba-ef17-4d9d-27c7-08d7bee86328 x-ms-traffictypediagnostic: DM6PR11MB3420: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(199004)(189003)(26005)(9686003)(86362001)(186003)(76116006)(966005)(498600001)(52536014)(64756008)(66446008)(66556008)(66946007)(4326008)(66476007)(71200400001)(2906002)(6506007)(8676002)(81156014)(81166006)(5660300002)(7696005)(33656002)(55016002)(8936002)(110136005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB3420; H:DM6PR11MB3915.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oAXdpt+wtpY/m7RzXjkPOcno/XNnPYcKUANfahIN3djb5EfXdOOXr1YU+RueWjJbS+ZCTXTgfQ8Z8BFU/y94Peo1NKXxnlUrYq3aujzVw5s/Gxa311TFhcWGJbBvUzgxH8X+0bo9QY/vwfEXv4cfLIt1AeOe87AQZ+CsiIVgqXl4l1VrKPoseOYYZuO/sEgH4wALdTFKQCXrVzX8UL4ts6KhGYJR1aTNrh/gXmePpmNFYK1wn/jieo7q/bT0Tl5fZ3M+LHKizl30IllhoIpcwcvjXtN29/xBnw46PFy9ZiNgY/ebKZKd15snJp5FQ0KZUaGj5RvH8++nbNp9FKzxi3ZNiAtn4Ofgt2OgSih3+iOyvAIc3+FG+nlVLNu57DJI7FgBIvq7NHsyNhcyToqGIMibRCZvyoaIO6hcK1OyWUOvgv8D5k1Z3bt+7tqGICaB+aruxsQbwvjdUSShojqkT16A3zt4a72Wo4BhsW6Rl9P/vY+7aBSy8Gne5TGY2az/2wMJwoL5rcjKCn5bzGdrHA== x-ms-exchange-antispam-messagedata: Y3NPLJZkqgOBOTZx6Owl7u05Gm7AYYucTw6ZTz0ygILZAHoJ6SfDaicFroHYzx2Z7qsI0zKMMZwaP7ypMi/jNHrthRwUAwbJB6RYyZU+Dk3Q85QTleGyhREXZkFn5GthZmq+8XS4daKSE5Oa47SaPw== 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-Network-Message-Id: 8f90bcba-ef17-4d9d-27c7-08d7bee86328 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 20:29:20.1250 (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: eiZaWJMHCYqU+U4XgI47XF4jR6CXh5T7MMaLgPgPcHqwX6c4M7A+k86DAyRpB4yWYzdKjHI7xQGhcwTpWsiw2ZOL30JXik2PfvA0jqYMhYyMuphaCohHW4wpGtAqUdGS X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3420 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 20:29:24 -0000 TXkgdHdvIGNlbnRzIG9uIOKAnGNyeXB0b2dyYXBoaWNhbGx5IHN0cm9uZyByYW5kb21uZXNz4oCd OiBkb27igJl0IHlvdSBhbHNvIG5lZWQgdG8gY29uc2lkZXIgYW4gYXR0YWNrIHRoYXQgcmVwbGF5 cyBzb21lYm9keSBlbHNl4oCZcyBPQ1NQIHJlc3BvbnNlPyBTbyBpbiBhZGRpdGlvbiB0byBhIGNs aWVudCBub3QgcmV1c2luZyB0aGUgc2FtZSBub25jZSBpbiBtdWx0aXBsZSByZXF1ZXN0cywgSSB0 aGluayB5b3UgYWxzbyBuZWVkIHRvIGF2b2lkIGhhdmluZyB5b3VyIG5vbmNlIGNvbGxpZGUgd2l0 aCBub25jZXMgZnJvbSBvdGhlciBjbGllbnRzIHdobyBhcmUgYXNraW5nIGFib3V0IHRoZSBzYW1l IGNlcnRpZmljYXRlLCByaWdodD8gQSBjcnlwdG9ncmFwaGljYWxseSByYW5kb20gMTYvMzIgYnl0 ZSBub25jZSBzZWVtcyBsaWtlIHRoZSB3YXkgdG8gZ28uDQoNCi0tLQ0KTWlrZSBPdW5zd29ydGgN ClNvZnR3YXJlIFNlY3VyaXR5IEFyY2hpdGVjdCwgRW50cnVzdCBEYXRhY2FyZA0KDQpGcm9tOiBT cGFzbSA8c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1vaGl0IFNhaG5pDQpT ZW50OiBNYXJjaCAyLCAyMDIwIDI6MDkgUE0NClRvOiBSdXNzIEhvdXNsZXkgPGhvdXNsZXlAdmln aWxzZWMuY29tPjsgdG9tYXMuZ3VzdGF2c3NvbkBwcmltZWtleS5jb20NCkNjOiBzcGFzbUBpZXRm Lm9yZw0KU3ViamVjdDogW0VYVEVSTkFMXVJlOiBbbGFtcHNdIFJGQzY5NjA6IElzc3VlIHdpdGgg dGhlIE9DU1AgTm9uY2UgZXh0ZW5zaW9uDQoNCldBUk5JTkc6IFRoaXMgZW1haWwgb3JpZ2luYXRl ZCBvdXRzaWRlIG9mIEVudHJ1c3QgRGF0YWNhcmQuDQpETyBOT1QgQ0xJQ0sgbGlua3Mgb3IgYXR0 YWNobWVudHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50 IGlzIHNhZmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpAVGhv bWFzOsKgDQpVc2luZyAiY3J5cHRvZ3JhcGhpY2FsbHkgc3Ryb25nIHJhbmRvbW5lc3MiIHRvIGdl bmVyYXRlIG5vbmNlIGlzIGEgZ29vZCBzdWdnZXN0aW9uIGFuZCBJIGFsc28gdGhvdWdodCBhYm91 dCBpdCB3aGlsZSB3cml0aW5nIHRoZSBkcmFmdC4gVGhlIHB1cnBvc2Ugb2Ygbm9uY2UgaW4gT0NT UCByZXF1ZXN0L3Jlc3BvbnNlIGlzIHRvIGRldGVjdCBhIHJlcGxheS4gQXMgbG9uZyBhcyBhIGNs aWVudCByZWNlaXZlcyB0aGUgc2FtZSBub25jZSBpbiByZXNwb25zZSBhcyB3aGF0IHRoZXkgc2Vu dCBpbiByZXF1ZXN0IGFuZCB0aGUgc2lnbmF0dXJlIGluIE9DU1AgcmVzcG9uc2UgY2FuIGJlIHZl cmlmaWVkIGFuZCB0cnVzdGVkIHRoZXkgc2hvdWxkIGFibGUgdG8gZGV0ZWN0IGEgcmVwbGF5IGF0 dGFjay4gSW4gbXkgb3BpbmlvbiBjbGllbnQgc2hvdWxkIG5vdCByZXVzZcKgdGhlIHNhbWUgbm9u Y2UgaW4gbXVsdGlwbGUgcmVxdWVzdHMsIHdlIGNhbiBlaXRoZXIgbWFuZGF0ZSBjbGllbnQgdG8g dXNlIGRpZmZlcmVudCBub25jZSBmb3IgZWFjaCByZXF1ZXN0IG1hZGUgaW4gYSBzcGVjaWZpZWQg d2luZG93IG9mIHRpbWUgb3Igd2UgY2FuIG1hbmRhdGUgY2xpZW50IHRvIHVzZSAiY3J5cHRvZ3Jh cGhpY2FsbHkgc3Ryb25nIHJhbmRvbW5lc3MiIHRvIGdldCBhIHJhbmRvbSBub25jZS4gUGxlYXNl IHN1Z2dlc3Qgd2hpY2ggYXBwcm9hY2jCoGlzIGJldHRlciBpbiB5b3VywqBvcGluaW9uLsKgDQoN CkBSdXNzLCBzdXJlLCBJIGFtIHRha2luZyBhIG5vdGUgb2YgYWRkaW5nIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb24gYWJvdXQgInVzaW5nIDEgb2N0ZXQgbm9uY2UiLsKgIFJlZ2FyZGluZyB0aGUgc2Vj dGlvbiAzLjEsIEkgYWRkZWQgaXQgdG8gaGlnaGxpZ2h0IHJpc2tzIGNyZWF0ZWQgYnkgdGhlIHJl Y29tbWVuZGF0aW9uIG1hZGUgaW7CoFJGQzUwMTksIHdoaWNoIHN1Z2dlc3RzIHRoYXQgaWYgc2Vy dmVyIGRvZXMgbm90IHNlbmQgYSBub25jZSBpbiBPQ1NQIHJlc3BvbnNlIHRoZW4gY2xpZW50IHNo b3VsZCBub3QgcmVqZWN0IHRoZSByZXNwb25zZSBqdXN0IGJlY2F1c2Ugbm9uY2UgaXMgbWlzc2lu ZyhodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTAxOSNzZWN0aW9uLTQpLiBJIGtub3cg aXRzIG91dCBvZiBjb250ZXh0IGhlcmUgYnV0IHN0aWxsIHdhbnRlZCB0byByZS1lbmZvcmNlIHRo YXQgdGhlcmUgaXMgYSByaXNrIG9mIHJlcGxheSBhdHRhY2sgaWYgY2xpZW50IGNob3NlIHRvIGFj Y2VwdCB0aGUgcmVzcG9uc2Ugd2l0aCB0aGUgbWlzc2luZyBub25jZS4NCg0KVGhhbmtzDQpNb2hp dMKgDQoNCk9uIE1vbiwgTWFyIDIsIDIwMjAgYXQgNzo0NyBBTSBSdXNzIEhvdXNsZXkgPG1haWx0 bzpob3VzbGV5QHZpZ2lsc2VjLmNvbT4gd3JvdGU6DQpBIG5vbmNlIG9mIDEgb2N0ZXQgZG9lcyBu b3QgcmVhbGx5IHByb3ZpZGUgdGhlIGludGVuZGVkIHByb3RlY3Rpb24uwqAgTWF5YmUgd2UgbW9y ZSBjb3VsZCBiZSBzYWlkIGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhYm91dCB0aGUg bWluaW11bSBzaXplLsKgIEFsc28sIHdoeSBpcyBTZWN0aW9uIDMuMSBpbmRlbnRlZD8NCg0KUnVz cw0KDQoNCg0KT24gTWFyIDIsIDIwMjAsIGF0IDEwOjIwIEFNLCBNb2hpdCBTYWhuaSA8bWFpbHRv Om1vaGl0MDZqYW5AZ21haWwuY29tPiB3cm90ZToNCg0KSGkgQWxsLA0KSSBzdGFydGVkIGEgdGhy ZWFkIGFib3V0IHRoZSBpc3N1ZXMgd2l0aCB0aGUgT0NTUCBOb25jZSBleHRlbnNpb24gd2hpY2jC oHdhcyBtaXNzaW5nIHRoZSBtYXhpbXVtwqBsZW5ndGggZm9yIHRoZSBOb25jZSBmaWVsZCBpbiB0 aGUgZXh0ZW5zaW9uIGFuZCBjb3VsZCBjcmVhdGXCoHBvdGVudGlhbMKgc2VjdXJpdHkgaXNzdWVz IHdpdGggdGhlIE9DU1AgcmVzcG9uZGVyIGZvbGxvd2luZyBSRkMgNjk2MC4gDQpodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwYXNtL05oOWZENHNtVFhuRjRtaE5ZbWJjVUxm Z0JTQS8NCg0KQmFzZWQgb24gdmFsdWFibGXCoGZlZWRiYWNrIHRoYXQgSSBnb3QgZnJvbSB0aGUg bWVtYmVycyBoZXJlLCBJIGhhdmUgd3JpdHRlbiBhIGRyYWZ0IGxpbWl0aW5nIHRoZSBsZW5ndGgg b2YgTm9uY2UgZXh0ZW5zaW9uwqBiZXR3ZWVuIDEtMzIgYnl0ZXMuwqAgSGVyZSBpcyB0aGUgbGlu ayB0byB0aGUgZHJhZnTCoGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1z YWhuaS1sYW1wcy1vY3NwLW5vbmNlLz9pbmNsdWRlX3RleHQ9MS4gUGxlYXNlIGxldCBtZSBrbm93 wqB3aGF0IHlvdSB0aGluay4NCg0KVGhhbmtzDQpNb2hpdCBTYWhuaQ0KDQo= From nobody Mon Mar 2 13:26: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 9E6AE3A11BA for ; Mon, 2 Mar 2020 13:26:35 -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 LZa8vYMsIWBr for ; Mon, 2 Mar 2020 13:26:34 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 DEFF63A11B6 for ; Mon, 2 Mar 2020 13:26:33 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id p8so785717iln.12 for ; Mon, 02 Mar 2020 13:26:33 -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=KtqWwooc0yqFAQB6bpedDetHRY7jra0dfEFSDQO/UZc=; b=lP40ua3+HD65KxS299slbvubQ5uqQE9ZlcCeJYedkT2KA8eUAihHxsW9oGbELni/F5 bC+HMTSiMFAmyf0YsvgYv3xjUJa7OH3/pmcDJNn9wj/4PFIfsnIuei59ttRWkfUou9ox 1Bcb5xl5P2TdTFXW5kpHsd2xvjO5BgpmuzR/7rPspGLRKRSM+AFPTZ8m+uJq0q9lkWJ1 QdhTIki1lztz/bGvNDPbBC2HMkbOJ4f8S3NJom7LycEKTbfKs4eWUpcBbXbCrFHvFZk2 l7TTnRZLbJYRWY0PbCDPD7imoMrRAL3sWmzo+4KiT/GS+TM/rEh6ly+Snitq/rQiGGyr Fa0A== 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=KtqWwooc0yqFAQB6bpedDetHRY7jra0dfEFSDQO/UZc=; b=dHSbLv4Ad2iM+XoLffQH+2ThsLZW9shwPed14oEFHNQk/5U3aT46bEoJdXkMXOfGOO U9I8yc7JtRVn3hxvZNIdb8V702zSAXaaABooivPsMneXofVP7c8YSw2Ml+sPpgIH7TW5 HMIaVaSF6ktsdwil4Kcuk0uQwgqPoQMZ1b+xk+cdytcWd3epzusve1oW1wFlPaaQSPy1 odMQugzOw+VOqvdJoD2U9VkRPtjdAcKbaUQjqBRRVvxGFwhsKAnCiVUuJJiWEfOWtI5q 35n+PKDsMq6U5zdzwK8QS6v92w8s4m1qs2bM69ANCa95g+mE4mw5XCZGfJ/5XDqpW0h7 n9NA== X-Gm-Message-State: ANhLgQ3Q/TsgRV2GczYbyV8RLxN6BcxEvPNdCktJCFhX5LZEU+a/sdIf DeoU0RG2qmAQuLMDRdZ1IbrDmN2bJ3077h8xSWg= X-Google-Smtp-Source: ADFU+vsNcUyQQ9yf6+a59gH2YujJv8DNzWWyLlm6a/hTxOn4foT4t6HOyTKdc9Bu0Q2zBjXRQs94mDQlHuSRmmfnvrM= X-Received: by 2002:a92:4a06:: with SMTP id m6mr1584170ilf.24.1583184393145; Mon, 02 Mar 2020 13:26:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Mon, 2 Mar 2020 13:26:22 -0800 Message-ID: To: Mike Ounsworth Cc: Russ Housley , "tomas.gustavsson@primekey.com" , "spasm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005e12aa059fe5d780" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:26:36 -0000 --0000000000005e12aa059fe5d780 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree to you regarding the nonce, collision and I will update the draft with statement that clients SHOULD use =E2=80=9Ccryptographically strong randomness=E2=80=9D and it's more secure to have nonce to be between 16-32 = octets long. -Mohit On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth < Mike.Ounsworth@entrustdatacard.com> wrote: > My two cents on =E2=80=9Ccryptographically strong randomness=E2=80=9D: do= n=E2=80=99t you also need > to consider an attack that replays somebody else=E2=80=99s OCSP response?= So in > addition to a client not reusing the same nonce in multiple requests, I > think you also need to avoid having your nonce collide with nonces from > other clients who are asking about the same certificate, right? A > cryptographically random 16/32 byte nonce seems like the way to go. > > --- > Mike Ounsworth > Software Security Architect, Entrust Datacard > > From: Spasm On Behalf Of Mohit Sahni > Sent: March 2, 2020 2:09 PM > To: Russ Housley ; tomas.gustavsson@primekey.com > Cc: spasm@ietf.org > Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce extensi= on > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and know th= e > content is safe. > ________________________________________ > @Thomas: > Using "cryptographically strong randomness" to generate nonce is a good > suggestion and I also thought about it while writing the draft. The purpo= se > of nonce in OCSP request/response is to detect a replay. As long as a > client receives the same nonce in response as what they sent in request a= nd > the signature in OCSP response can be verified and trusted they should ab= le > to detect a replay attack. In my opinion client should not reuse the same > nonce in multiple requests, we can either mandate client to use different > nonce for each request made in a specified window of time or we can manda= te > client to use "cryptographically strong randomness" to get a random nonce= . > Please suggest which approach is better in your opinion. > > @Russ, sure, I am taking a note of adding security consideration about > "using 1 octet nonce". Regarding the section 3.1, I added it to highligh= t > risks created by the recommendation made in RFC5019, which suggests that = if > server does not send a nonce in OCSP response then client should not reje= ct > the response just because nonce is missing( > https://tools.ietf.org/html/rfc5019#section-4). I know its out of context > here but still wanted to re-enforce that there is a risk of replay attack > if client chose to accept the response with the missing nonce. > > Thanks > Mohit > > On Mon, Mar 2, 2020 at 7:47 AM Russ Housley > wrote: > A nonce of 1 octet does not really provide the intended protection. Mayb= e > we more could be said in the Security Considerations about the minimum > size. Also, why is Section 3.1 indented? > > Russ > > > > On Mar 2, 2020, at 10:20 AM, Mohit Sahni > wrote: > > Hi All, > I started a thread about the issues with the OCSP Nonce extension > which was missing the maximum length for the Nonce field in the extension > and could create potential security issues with the OCSP responder > following RFC 6960. > https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ > > Based on valuable feedback that I got from the members here, I have > written a draft limiting the length of Nonce extension between 1-32 bytes= . > Here is the link to the draft > https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_t= ext=3D1. > Please let me know what you think. > > Thanks > Mohit Sahni > > --0000000000005e12aa059fe5d780 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree to you=C2=A0regarding the nonce, collision=C2=A0an= d I will update the draft with statement that clients SHOULD use =E2=80=9Cc= ryptographically strong randomness=E2=80=9D and it's more secure to hav= e nonce to be between 16-32 octets long.=C2=A0

-Mohit=C2= =A0

On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:
My= two cents on =E2=80=9Ccryptographically strong randomness=E2=80=9D: don=E2= =80=99t you also need to consider an attack that replays somebody else=E2= =80=99s OCSP response? So in addition to a client not reusing the same nonc= e in multiple requests, I think you also need to avoid having your nonce co= llide with nonces from other clients who are asking about the same certific= ate, right? A cryptographically random 16/32 byte nonce seems like the way = to go.

---
Mike Ounsworth
Software Security Architect, Entrust Datacard

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mohit Sahni
Sent: March 2, 2020 2:09 PM
To: Russ Housley <housley@vigilsec.com>; tomas.gustavsson@primekey.com
Cc: spasm@ietf.org<= br> Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce extension=

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe.
________________________________________
@Thomas:=C2=A0
Using "cryptographically strong randomness" to generate nonce is = a good suggestion and I also thought about it while writing the draft. The = purpose of nonce in OCSP request/response is to detect a replay. As long as= a client receives the same nonce in response as what they sent in request = and the signature in OCSP response can be verified and trusted they should = able to detect a replay attack. In my opinion client should not reuse=C2=A0= the same nonce in multiple requests, we can either mandate client to use di= fferent nonce for each request made in a specified window of time or we can= mandate client to use "cryptographically strong randomness" to g= et a random nonce. Please suggest which approach=C2=A0is better in your=C2= =A0opinion.=C2=A0

@Russ, sure, I am taking a note of adding security consideration about &quo= t;using 1 octet nonce".=C2=A0 Regarding the section 3.1, I added it to= highlight risks created by the recommendation made in=C2=A0RFC5019, which = suggests that if server does not send a nonce in OCSP response then client = should not reject the response just because nonce is missing(https://tools.ietf.org/html/rfc5019#section-4). I know its out of= context here but still wanted to re-enforce that there is a risk of replay= attack if client chose to accept the response with the missing nonce.

Thanks
Mohit=C2=A0

On Mon, Mar 2, 2020 at 7:47 AM Russ Housley <mailto:housley@vigilsec.com> wrote: A nonce of 1 octet does not really provide the intended protection.=C2=A0 M= aybe we more could be said in the Security Considerations about the minimum= size.=C2=A0 Also, why is Section 3.1 indented?

Russ



On Mar 2, 2020, at 10:20 AM, Mohit Sahni <mailto:mohit06jan@gmail.com> wrote:

Hi All,
I started a thread about the issues with the OCSP Nonce extension which=C2= =A0was missing the maximum=C2=A0length for the Nonce field in the extension= and could create=C2=A0potential=C2=A0security issues with the OCSP respond= er following RFC 6960.
https://mailarchive.ietf.org= /arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/

Based on valuable=C2=A0feedback that I got from the members here, I have wr= itten a draft limiting the length of Nonce extension=C2=A0between 1-32 byte= s.=C2=A0 Here is the link to the draft=C2=A0https://datatracker.ietf.org/doc/draft-msahni-lamps= -ocsp-nonce/?include_text=3D1. Please let me know=C2=A0what you think.<= br>
Thanks
Mohit Sahni

--0000000000005e12aa059fe5d780-- From nobody Mon Mar 2 13: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 40F8C3A11D5 for ; Mon, 2 Mar 2020 13:30:57 -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=primekey.com header.b=hPu7od3P; dkim=pass (1024-bit key) header.d=primekey.com header.b=UG8Rfjnw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcZskSVjmzeM for ; Mon, 2 Mar 2020 13:30:54 -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 95EC53A11D1 for ; Mon, 2 Mar 2020 13:30:54 -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 04E1C6AA009D; Mon, 2 Mar 2020 22:30:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583184640; bh=kkj2bk9hKkBLde/ks41LSqlPiHZ1eS+//x8PzxtFYbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hPu7od3PgrVDPbyLOLFGwenMJPNeu1JwepzN/b9+ByH0VqN5GX1EsfipQwWTYug7i l3IcPfO3DmfksAiMfPIIjUiXYlIJP5jTxgi9RMQA5SCe7zyOay6cV35+mNjDK5/ATM 5xjy4bx63kkF/YLrSSPGk6FdbyS1IdrIYcnn9oNA= Received: from [10.33.2.27] (base.c2company.com [173.167.113.17]) (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 D51036AA0099; Mon, 2 Mar 2020 22:30:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583184639; bh=kkj2bk9hKkBLde/ks41LSqlPiHZ1eS+//x8PzxtFYbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UG8RfjnwNx/4IjjM2+r1UdBzjDudOplnJsA72JQNyUBa2QER0Czn/h1JE9cj86SQC XTQmdcOgiUZkhob4YdbCK2efZw4/4BJ0XZmFxLn2jSFop8JCajoHfEWh6YlbOiH7kF gTLc/5m2VuOUDkWPymirEnGuN1lv7iEYwjmp3+WI= To: Mohit Sahni , Mike Ounsworth Cc: Russ Housley , "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: Date: Mon, 2 Mar 2020 13:30:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:30:57 -0000 Agreed. And never re-use a nonce, should be new, random, for every request. Cheers, Tomas On 2020-03-02 13:26, Mohit Sahni wrote: > I agree to you regarding the nonce, collision and I will update the > draft with statement that clients SHOULD use “cryptographically strong > randomness” and it's more secure to have nonce to be between 16-32 > octets long.  > > -Mohit  > > On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth > > wrote: > > My two cents on “cryptographically strong randomness”: don’t you > also need to consider an attack that replays somebody else’s OCSP > response? So in addition to a client not reusing the same nonce in > multiple requests, I think you also need to avoid having your nonce > collide with nonces from other clients who are asking about the same > certificate, right? A cryptographically random 16/32 byte nonce > seems like the way to go. > > --- > Mike Ounsworth > Software Security Architect, Entrust Datacard > > From: Spasm > > On Behalf Of Mohit Sahni > Sent: March 2, 2020 2:09 PM > To: Russ Housley >; tomas.gustavsson@primekey.com > > Cc: spasm@ietf.org > Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce > extension > > WARNING: This email originated outside of Entrust Datacard. > DO NOT CLICK links or attachments unless you trust the sender and > know the content is safe. > ________________________________________ > @Thomas:  > Using "cryptographically strong randomness" to generate nonce is a > good suggestion and I also thought about it while writing the draft. > The purpose of nonce in OCSP request/response is to detect a replay. > As long as a client receives the same nonce in response as what they > sent in request and the signature in OCSP response can be verified > and trusted they should able to detect a replay attack. In my > opinion client should not reuse the same nonce in multiple requests, > we can either mandate client to use different nonce for each request > made in a specified window of time or we can mandate client to use > "cryptographically strong randomness" to get a random nonce. Please > suggest which approach is better in your opinion.  > > @Russ, sure, I am taking a note of adding security consideration > about "using 1 octet nonce".  Regarding the section 3.1, I added it > to highlight risks created by the recommendation made in RFC5019, > which suggests that if server does not send a nonce in OCSP response > then client should not reject the response just because nonce is > missing(https://tools.ietf.org/html/rfc5019#section-4). I know its > out of context here but still wanted to re-enforce that there is a > risk of replay attack if client chose to accept the response with > the missing nonce. > > Thanks > Mohit  > > On Mon, Mar 2, 2020 at 7:47 AM Russ Housley > > wrote: > A nonce of 1 octet does not really provide the intended protection.  > Maybe we more could be said in the Security Considerations about the > minimum size.  Also, why is Section 3.1 indented? > > Russ > > > > On Mar 2, 2020, at 10:20 AM, Mohit Sahni > > wrote: > > Hi All, > I started a thread about the issues with the OCSP Nonce extension > which was missing the maximum length for the Nonce field in the > extension and could create potential security issues with the OCSP > responder following RFC 6960. > https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ > > Based on valuable feedback that I got from the members here, I have > written a draft limiting the length of Nonce extension between 1-32 > bytes.  Here is the link to the > draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. > Please let me know what you think. > > Thanks > Mohit Sahni > From nobody Mon Mar 2 13:33: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 C6E803A11FF for ; Mon, 2 Mar 2020 13:33:26 -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 0PkUgJRFCV89 for ; Mon, 2 Mar 2020 13:33:24 -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 5C15E3A120C for ; Mon, 2 Mar 2020 13:33:24 -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 022LBULt027925; Mon, 2 Mar 2020 21:33:21 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=UtZXZMzMPcfvAJ7oG3uFX7Gj+diy5d+5eAUZq0STg+8=; b=lBQoN13SuBKkq0EBfVedRJbzq1Ne9VeiQH3kO7rNCIBx8rfMR5CK1tmzb8A3PWsk3fbE bRJHYOs9YmwHInGCMf8cxDEp5u8dEkInPALmel4XLRXJEVTKkFIpWJa3UOPkc6tV3WjV yhQ2Y+dF532qqRSpxt9SIjjcUcwxdM5wXSkjJjQzk1vtEmSAFzE33ADOuxjQDLy9ztJl 5tSdwjPyYgPcTW8QYzkVO92AnLjlOnTMSp/wiCNO7sGwWVtQ003YJEKNT57vbI2rua2g VUMCVPioNbLj+ylfNS7z8iKeDee/Qo+PuSeIn1SrXRiVtlPgLKi2ZKqiPZ5IxN4w4nQl 2A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2yfdwktpkf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Mar 2020 21:33:21 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 022LWWCB017688; Mon, 2 Mar 2020 16:33:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2yfm5yxq67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Mar 2020 16:33:20 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 16:33:19 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Mon, 2 Mar 2020 16:33:19 -0500 From: "Salz, Rich" To: Tomas Gustavsson , Mohit Sahni , Mike Ounsworth CC: "spasm@ietf.org" , Russ Housley Thread-Topic: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension Thread-Index: AQHV8NGO7whWEqb6uEGGjBNZt2gUw6g2JJ8AgAABPQD//6zigA== Date: Mon, 2 Mar 2020 21:33:19 +0000 Message-ID: <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20022603 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.121] 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.138, 18.0.572 definitions=2020-03-02_08:2020-03-02, 2020-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=830 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2003020139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-02_08:2020-03-02, 2020-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=795 priorityscore=1501 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003020138 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:33:34 -0000 V2hpY2ggaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBjcnlwdG9ncmFwaGljYWxseSBzdHJvbmcuICBB IG9uZS1ieXRlIHZhbHVlICBjYW4gYWxsIHRvbyBlYXNpbHkgd3JhcC4gIEEgMzJiaXQgc2VxdWVu Y2UgbnVtYmVyIHByb2JhYmx5IHN1ZmZpY2VzLg0KDQrvu79PbiAzLzIvMjAsIDQ6MzIgUE0sICJU b21hcyBHdXN0YXZzc29uIiA8dG9tYXMuZ3VzdGF2c3NvbkBwcmltZWtleS5jb20+IHdyb3RlOg0K DQogICAgDQogICAgQWdyZWVkLiBBbmQgbmV2ZXIgcmUtdXNlIGEgbm9uY2UsIHNob3VsZCBiZSBu ZXcsIHJhbmRvbSwgZm9yIGV2ZXJ5IHJlcXVlc3QuDQogICAgDQogICAgQ2hlZXJzLA0KICAgIFRv bWFzDQogICAgDQogICAgT24gMjAyMC0wMy0wMiAxMzoyNiwgTW9oaXQgU2Fobmkgd3JvdGU6DQog ICAgPiBJIGFncmVlIHRvIHlvdSByZWdhcmRpbmcgdGhlIG5vbmNlLCBjb2xsaXNpb24gYW5kIEkg d2lsbCB1cGRhdGUgdGhlDQogICAgPiBkcmFmdCB3aXRoIHN0YXRlbWVudCB0aGF0IGNsaWVudHMg U0hPVUxEIHVzZSDigJxjcnlwdG9ncmFwaGljYWxseSBzdHJvbmcNCiAgICA+IHJhbmRvbW5lc3Pi gJ0gYW5kIGl0J3MgbW9yZSBzZWN1cmUgdG8gaGF2ZSBub25jZSB0byBiZSBiZXR3ZWVuIDE2LTMy DQogICAgPiBvY3RldHMgbG9uZy4gDQogICAgDQoNCg0K From nobody Mon Mar 2 13:49: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 11B283A1296 for ; Mon, 2 Mar 2020 13:49:12 -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 ME_QEzuG0l_l for ; Mon, 2 Mar 2020 13:49:06 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 83B553A12C6 for ; Mon, 2 Mar 2020 13:49:06 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id r15so1223356iog.0 for ; Mon, 02 Mar 2020 13:49:06 -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=wrLwCyeX7UKUDyM4G+pClfP4yYvLFZc/sW8jwbYuBnU=; b=sIDefainUgd8DHrXyDa6M8KuulMsjrKUfuqxu/vTMCSQrMtYSjeKxk96aROB4yDJTC IvjRnpzbf3ICuNLPOBy6pfAXBGRq9v7rE0WA3F77yh9Q6ZKMXGUJI2DvPXobGQOezbnK xJ1cCwPJx1fsHGOaQzfPM1pMUYHEX641azDkBH/WXGtqOzrdV3VSW36g5LtqnR0DvsGk XP4txQQNyckuSfYf4HVYqOfQcN48Z4QUFqKozcPrY+nkw6vo11w3fwQkB2vm+NFl4La8 579jfu1juOK5iEFDoqJ+QAF5v6F/RUivmJIMKr9kaw8r7vSsPcyOwakPIX3LP2DsWqbJ 7JuQ== 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=wrLwCyeX7UKUDyM4G+pClfP4yYvLFZc/sW8jwbYuBnU=; b=gx0nXICfCEAG4Xs2Mc/s7ijGe36sCuQEexfb3CKmr3My0Nci9jcciN8Kl0pbY46jqo 4VzSBq7E3EWE4xfkaCnCBA+AwdpllZJflKxYoEF4OYOLAJ2H6wz4ZnJPW68OxNdDfcZT +CsMqj9XDoKiSRVsgyxpROfw822Z/fkD2eaA7xikRT8RgxyIxNkEk3DjM4q3TZLebNgx zoJ2LuuuHVmRYyuXJceuYETFTBoHCtHRtM18D2ejAk/fQBlQXaWGiyAIxNBkjtX0/yEM eLfgF1VQJwqs4tLYzfOFdxB3pviyzXKyIKIbm+fw7vKpojRG/SjrvcZtQiSBU9JPNpo7 MhZw== X-Gm-Message-State: ANhLgQ1JLZ7i10/kkHCH4QVAI+balA/s8DSYEwNBIBAc/QyX4mVgSm6w rgGkTWLqrxrcM8dGb3DuzA4s6luEn3XE4FrWaxc= X-Google-Smtp-Source: ADFU+vuAsShO//HgGd1SrCHCSYO+JVKki+WzQdDGovAWbMu9CU9lBjymYJ/WTOFzBeXXNFnACKXAmCYwqRCNWYCEWLI= X-Received: by 2002:a02:7317:: with SMTP id y23mr1089005jab.85.1583185745800; Mon, 02 Mar 2020 13:49:05 -0800 (PST) MIME-Version: 1.0 References: <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> In-Reply-To: <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> From: Mohit Sahni Date: Mon, 2 Mar 2020 13:48:54 -0800 Message-ID: To: "Salz, Rich" Cc: Tomas Gustavsson , Mike Ounsworth , "spasm@ietf.org" , Russ Housley Content-Type: multipart/alternative; boundary="000000000000fdf219059fe62759" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:49:18 -0000 --000000000000fdf219059fe62759 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rich, Currently RFC 6960 defines the OCSP nonce in section 4.4.1 and it does not mention anything about minimum and a maximum length on nonce. I proposed a range for length as1-32 octets keeping in mind the backward compatibility. There may be some older clients and responders which may be sending/processing different lengths of nonce. Based on the feedback by Thomas, I proposed an upper bound of 32 as its already working in a popular PKI implementation and they have not seen any issues with that. Please see this link for more background on this: https://mailarchive.ietf.org/arch/msg/spasm/2aKuvO6YomMsxbuCv4lHq05Uaac/ I will add text to strongly suggest that a nonce length should be between 16-32 octets and make sure implementations know the risk of using smaller size nonce. Thanks Mohit On Mon, Mar 2, 2020 at 1:33 PM Salz, Rich wrote: > Which is more important than cryptographically strong. A one-byte value > can all too easily wrap. A 32bit sequence number probably suffices. > > =EF=BB=BFOn 3/2/20, 4:32 PM, "Tomas Gustavsson" > wrote: > > > Agreed. And never re-use a nonce, should be new, random, for every > request. > > Cheers, > Tomas > > On 2020-03-02 13:26, Mohit Sahni wrote: > > I agree to you regarding the nonce, collision and I will update the > > draft with statement that clients SHOULD use =E2=80=9Ccryptographic= ally > strong > > randomness=E2=80=9D and it's more secure to have nonce to be betwee= n 16-32 > > octets long. > > > > --000000000000fdf219059fe62759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rich,
Currently RFC 6960 defines the OCSP nonce in = section 4.4.1 and it does not mention anything about minimum and a maximum = length on nonce. I proposed a range for length as1-32=C2=A0octets keeping i= n mind the backward compatibility. There may be some older clients and resp= onders which may be sending/processing different lengths of nonce.=C2=A0Bas= ed on the feedback by Thomas, I proposed an upper bound of 32 as its alread= y working in a popular PKI implementation and they have not seen any issues= with that. Please see this link for more background on this:=C2=A0
https://mailarchive.ietf.org/arch/msg/spasm/2aKuvO6YomMsxbuCv4= lHq05Uaac/=C2=A0

I will add text to strong= ly suggest that a nonce length should be between 16-32 octets and make sure= implementations know the risk of using smaller size nonce.=C2=A0

Thanks
Mohit=C2=A0

On Mon, Mar 2, 2020 at 1:= 33 PM Salz, Rich <rsalz@akamai.com> wrote:
Wh= ich is more important than cryptographically strong.=C2=A0 A one-byte value= =C2=A0 can all too easily wrap.=C2=A0 A 32bit sequence number probably suff= ices.

=EF=BB=BFOn 3/2/20, 4:32 PM, "Tomas Gustavsson" <tomas.gustavsson@prim= ekey.com> wrote:


=C2=A0 =C2=A0 Agreed. And never re-use a nonce, should be new, random, for = every request.

=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 Tomas

=C2=A0 =C2=A0 On 2020-03-02 13:26, Mohit Sahni wrote:
=C2=A0 =C2=A0 > I agree to you regarding the nonce, collision and I will= update the
=C2=A0 =C2=A0 > draft with statement that clients SHOULD use =E2=80=9Ccr= yptographically strong
=C2=A0 =C2=A0 > randomness=E2=80=9D and it's more secure to have non= ce to be between 16-32
=C2=A0 =C2=A0 > octets long.



--000000000000fdf219059fe62759-- From nobody Mon Mar 2 13:50: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 B0A743A0871 for ; Mon, 2 Mar 2020 13:50:09 -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 Dpl9HcxDkfL9 for ; Mon, 2 Mar 2020 13:50:07 -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 35DBF3A07D6 for ; Mon, 2 Mar 2020 13:50:07 -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 022LlcN4006909; Mon, 2 Mar 2020 21:50: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 : mime-version; s=jan2016.eng; bh=s8sEyj7nidJYGmtmI3NDt+Me40IPEId3QFyxMuS4tUw=; b=Law2JZyW/KA4cLnlAHpPoxAITm8giEMxqypE3m3UkV12UsXPHt30yrX+WcFnLzVs9j+d mhQtoNAxcJWJXb5vKEtUN5vxdTRxap5keXf0eLk1lSKUZnDaRF21ZgGufn9rrvKC+qzH O2heqFCCPD5+SKhbgw+A5DHWWjHSBsimwLcR519N6jzHUYxOSyURqQTS7QIY6ZkR2cEM /o/+lFoY3yd0/+UBqhLXix/NyeepeFYJ+xcjFnxFPYgTm/bKjLvBB5mR5MS8FPyJWv5n LcBcGClybAe+7jyZGPqqI5gdHWyEjsi9D2+dKqn35jJO4KA7DHZRg1czejzuTHuHywHe Gg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2yfgg2hqnr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Mar 2020 21:50:04 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 022LWZee017751; Mon, 2 Mar 2020 16:50:04 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2yfm5yxr8j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Mar 2020 16:50:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 16:50:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Mon, 2 Mar 2020 16:50:03 -0500 From: "Salz, Rich" To: Mohit Sahni CC: Tomas Gustavsson , Mike Ounsworth , "spasm@ietf.org" , "Russ Housley" Thread-Topic: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension Thread-Index: AQHV8NGO7whWEqb6uEGGjBNZt2gUw6g2JJ8AgAABPQD//6zigIAAWCwA//+sgYA= Date: Mon, 2 Mar 2020 21:50:02 +0000 Message-ID: References: <96FC0A60-3642-4BF3-8237-E204F1F37994@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.35.20022603 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.121] Content-Type: multipart/alternative; boundary="_000_E17B3887C1924DEC827A77E798B66F88akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-02_08:2020-03-02, 2020-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=843 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002050000 definitions=main-2003020139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-02_09:2020-03-02, 2020-03-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 mlxlogscore=822 priorityscore=1501 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2003020140 Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:50:10 -0000 --_000_E17B3887C1924DEC827A77E798B66F88akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3aWxsIGFkZCB0ZXh0IHRvIHN0cm9uZ2x5IHN1Z2dlc3QgdGhhdCBhIG5vbmNlIGxl bmd0aCBzaG91bGQgYmUgYmV0d2VlbiAxNi0zMiBvY3RldHMgYW5kIG1ha2Ugc3VyZSBpbXBsZW1l bnRhdGlvbnMga25vdyB0aGUgcmlzayBvZiB1c2luZyBzbWFsbGVyIHNpemUgbm9uY2UuDQoNClRo YXTigJlzIGZpbmUgd2l0aCBtZSwgdGhhbmtzLg0K --_000_E17B3887C1924DEC827A77E798B66F88akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <941BCC9A6B5933429D6EC2242A93FC29@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjYx ODgyMzYzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTIxODY1MjMwNCAtMTY0ODQ5MTI0OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t YmlkaS1mb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t YmlkaS1mb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRp dj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+SSB3aWxsIGFkZCB0ZXh0IHRvIHN0cm9uZ2x5IHN1Z2dlc3QgdGhhdCBh IG5vbmNlIGxlbmd0aCBzaG91bGQgYmUgYmV0d2VlbiAxNi0zMiBvY3RldHMgYW5kIG1ha2Ugc3Vy ZSBpbXBsZW1lbnRhdGlvbnMga25vdyB0aGUgcmlzayBvZiB1c2luZyBzbWFsbGVyIHNpemUgbm9u Y2UuJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGZpbmUgd2l0 aCBtZSwgdGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_E17B3887C1924DEC827A77E798B66F88akamaicom_-- From nobody Mon Mar 2 13:58: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 5943F3A1277 for ; Mon, 2 Mar 2020 13:58: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, 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=primekey.com header.b=YoRGsSwu; dkim=pass (1024-bit key) header.d=primekey.com header.b=YoRGsSwu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfEObItm_Req for ; Mon, 2 Mar 2020 13:58:39 -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 350363A1276 for ; Mon, 2 Mar 2020 13:58: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 768CD6AA009C for ; Mon, 2 Mar 2020 22:58:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583186304; bh=M31CFE24MPP+Dj59EswyW/vkdLWkFgGq36aSCPaXfhs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YoRGsSwu+FByFviXNqngKUQ9HDHzlBba639nvFV2wRVYj3vDhGIga142ys8T4VTRy S2BEInXn56NCb6Qu7IkMb2Xy4z8KRs+5V0e1mjAokOPEIqfzR9DAn9DfAxWFNQVRO6 Ryu6dIIlnPVIkPS6Hew7aVezIm8yhPHKVX9L4F/w= Received: from [10.33.2.27] (base.c2company.com [173.167.113.17]) (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 EF8426AA0090 for ; Mon, 2 Mar 2020 22:58:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583186304; bh=M31CFE24MPP+Dj59EswyW/vkdLWkFgGq36aSCPaXfhs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YoRGsSwu+FByFviXNqngKUQ9HDHzlBba639nvFV2wRVYj3vDhGIga142ys8T4VTRy S2BEInXn56NCb6Qu7IkMb2Xy4z8KRs+5V0e1mjAokOPEIqfzR9DAn9DfAxWFNQVRO6 Ryu6dIIlnPVIkPS6Hew7aVezIm8yhPHKVX9L4F/w= To: spasm@ietf.org References: <96FC0A60-3642-4BF3-8237-E204F1F37994@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: <64504da8-289e-70d2-4e87-ed140fa0c100@primekey.com> Date: Mon, 2 Mar 2020 13:58:34 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 21:58:42 -0000 As the Nonce is set by the client the server can not enforce a minimum length. The server typically just copied the nonce from the request into the response. Now it's also checking that the client does not send more than 32 bytes as nonce and will give a Unauthorized response if the nonce sent by the client is >32 bytes. So, there is a client-server separation. - minimal size is a recommendation for OCSP clients - maximum size is a limit enforced by the OCSP responder Cheers, Tomas On 2020-03-02 13:50, Salz, Rich wrote: > * I will add text to strongly suggest that a nonce length should be > between 16-32 octets and make sure implementations know the risk of > using smaller size nonce.  > >   > > That’s fine with me, thanks. > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon Mar 2 14:06: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 EAD653A129D for ; Mon, 2 Mar 2020 14:06:08 -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 qVdV30ItNz1d for ; Mon, 2 Mar 2020 14:06:07 -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 215B23A1295 for ; Mon, 2 Mar 2020 14:06:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 78765300B51 for ; Mon, 2 Mar 2020 17:06:04 -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 z3ylLNyX-9gc for ; Mon, 2 Mar 2020 17:06:01 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id A51E53004C0; Mon, 2 Mar 2020 17:06:01 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Mon, 2 Mar 2020 17:06:03 -0500 Cc: Mohit Sahni , Mike Ounsworth , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tomas Gustavsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 22:06:09 -0000 I think you mean a freshly generated random value. You do not mean that = an implementation should make sure that it has not previously used that = particular value. Russ > On Mar 2, 2020, at 4:30 PM, Tomas Gustavsson = wrote: >=20 >=20 > Agreed. And never re-use a nonce, should be new, random, for every = request. >=20 > Cheers, > Tomas >=20 > On 2020-03-02 13:26, Mohit Sahni wrote: >> I agree to you regarding the nonce, collision and I will update the >> draft with statement that clients SHOULD use =E2=80=9Ccryptographically= strong >> randomness=E2=80=9D and it's more secure to have nonce to be between = 16-32 >> octets long.=20 >>=20 >> -Mohit=20 >>=20 >> On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth >> > > wrote: >>=20 >> My two cents on =E2=80=9Ccryptographically strong randomness=E2=80=9D= : don=E2=80=99t you >> also need to consider an attack that replays somebody else=E2=80=99s= OCSP >> response? So in addition to a client not reusing the same nonce in >> multiple requests, I think you also need to avoid having your = nonce >> collide with nonces from other clients who are asking about the = same >> certificate, right? A cryptographically random 16/32 byte nonce >> seems like the way to go. >>=20 >> --- >> Mike Ounsworth >> Software Security Architect, Entrust Datacard >>=20 >> From: Spasm > >> On Behalf Of Mohit Sahni >> Sent: March 2, 2020 2:09 PM >> To: Russ Housley > >; tomas.gustavsson@primekey.com >> >> Cc: spasm@ietf.org >> Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce >> extension >>=20 >> WARNING: This email originated outside of Entrust Datacard. >> DO NOT CLICK links or attachments unless you trust the sender and >> know the content is safe. >> ________________________________________ >> @Thomas:=20 >> Using "cryptographically strong randomness" to generate nonce is a >> good suggestion and I also thought about it while writing the = draft. >> The purpose of nonce in OCSP request/response is to detect a = replay. >> As long as a client receives the same nonce in response as what = they >> sent in request and the signature in OCSP response can be verified >> and trusted they should able to detect a replay attack. In my >> opinion client should not reuse the same nonce in multiple = requests, >> we can either mandate client to use different nonce for each = request >> made in a specified window of time or we can mandate client to use >> "cryptographically strong randomness" to get a random nonce. = Please >> suggest which approach is better in your opinion.=20 >>=20 >> @Russ, sure, I am taking a note of adding security consideration >> about "using 1 octet nonce". Regarding the section 3.1, I added = it >> to highlight risks created by the recommendation made in RFC5019, >> which suggests that if server does not send a nonce in OCSP = response >> then client should not reject the response just because nonce is >> missing(https://tools.ietf.org/html/rfc5019#section-4). I know its >> out of context here but still wanted to re-enforce that there is a >> risk of replay attack if client chose to accept the response with >> the missing nonce. >>=20 >> Thanks >> Mohit=20 >>=20 >> On Mon, Mar 2, 2020 at 7:47 AM Russ Housley >> > wrote: >> A nonce of 1 octet does not really provide the intended = protection.=20 >> Maybe we more could be said in the Security Considerations about = the >> minimum size. Also, why is Section 3.1 indented? >>=20 >> Russ >>=20 >>=20 >>=20 >> On Mar 2, 2020, at 10:20 AM, Mohit Sahni >> > wrote: >>=20 >> Hi All, >> I started a thread about the issues with the OCSP Nonce extension >> which was missing the maximum length for the Nonce field in the >> extension and could create potential security issues with the OCSP >> responder following RFC 6960. >> = https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ >>=20 >> Based on valuable feedback that I got from the members here, I = have >> written a draft limiting the length of Nonce extension between = 1-32 >> bytes. Here is the link to the >> draft = https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_te= xt=3D1. >> Please let me know what you think. >>=20 >> Thanks >> Mohit Sahni >>=20 From nobody Mon Mar 2 14:12: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 CE30A3A12C8 for ; Mon, 2 Mar 2020 14:12:03 -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, 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=primekey.com header.b=EVWxM9Ka; dkim=pass (1024-bit key) header.d=primekey.com header.b=EVWxM9Ka Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkTCDyDklvw0 for ; Mon, 2 Mar 2020 14:12:01 -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 9E9E63A12C6 for ; Mon, 2 Mar 2020 14:12:00 -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 C688B6AA009C for ; Mon, 2 Mar 2020 23:11:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583187105; bh=s9YmSRvx+hlIn6fkOw+rgi6RRM/iBnI900Ud80zCNbY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EVWxM9KaWxyCYHHby9/byFsppG2ifHdirTxA8VI2hh4Xb/CzPyeUqF9p7XFVvt9fP 9ci1uo5f6MUydHuZ5EpwA34D94iP6o/nIWlKRNTqg6sPEv5IeksPRU9fieE9xyhhDT CwVolX2VnZchfOdmLv881crscZ4Mu3gcELyO01Zs= Received: from [10.33.2.27] (base.c2company.com [173.167.113.17]) (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 433A66AA0090 for ; Mon, 2 Mar 2020 23:11:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1583187105; bh=s9YmSRvx+hlIn6fkOw+rgi6RRM/iBnI900Ud80zCNbY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EVWxM9KaWxyCYHHby9/byFsppG2ifHdirTxA8VI2hh4Xb/CzPyeUqF9p7XFVvt9fP 9ci1uo5f6MUydHuZ5EpwA34D94iP6o/nIWlKRNTqg6sPEv5IeksPRU9fieE9xyhhDT CwVolX2VnZchfOdmLv881crscZ4Mu3gcELyO01Zs= 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: <0d49d897-4be9-3c8e-4dbd-bf7eb6f3f337@primekey.com> Date: Mon, 2 Mar 2020 14:11:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 22:12:04 -0000 On 2020-03-02 14:06, Russ Housley wrote: > I think you mean a freshly generated random value. You do not mean that an implementation should make sure that it has not previously used that particular value. Correct, that's what I mean. > > Russ > > >> On Mar 2, 2020, at 4:30 PM, Tomas Gustavsson wrote: >> >> >> Agreed. And never re-use a nonce, should be new, random, for every request. >> >> Cheers, >> Tomas >> >> On 2020-03-02 13:26, Mohit Sahni wrote: >>> I agree to you regarding the nonce, collision and I will update the >>> draft with statement that clients SHOULD use “cryptographically strong >>> randomness” and it's more secure to have nonce to be between 16-32 >>> octets long. >>> >>> -Mohit >>> >>> On Mon, Mar 2, 2020 at 12:29 PM Mike Ounsworth >>> >> > wrote: >>> >>> My two cents on “cryptographically strong randomness”: don’t you >>> also need to consider an attack that replays somebody else’s OCSP >>> response? So in addition to a client not reusing the same nonce in >>> multiple requests, I think you also need to avoid having your nonce >>> collide with nonces from other clients who are asking about the same >>> certificate, right? A cryptographically random 16/32 byte nonce >>> seems like the way to go. >>> >>> --- >>> Mike Ounsworth >>> Software Security Architect, Entrust Datacard >>> >>> From: Spasm > >>> On Behalf Of Mohit Sahni >>> Sent: March 2, 2020 2:09 PM >>> To: Russ Housley >> >; tomas.gustavsson@primekey.com >>> >>> Cc: spasm@ietf.org >>> Subject: [EXTERNAL]Re: [lamps] RFC6960: Issue with the OCSP Nonce >>> extension >>> >>> WARNING: This email originated outside of Entrust Datacard. >>> DO NOT CLICK links or attachments unless you trust the sender and >>> know the content is safe. >>> ________________________________________ >>> @Thomas: >>> Using "cryptographically strong randomness" to generate nonce is a >>> good suggestion and I also thought about it while writing the draft. >>> The purpose of nonce in OCSP request/response is to detect a replay. >>> As long as a client receives the same nonce in response as what they >>> sent in request and the signature in OCSP response can be verified >>> and trusted they should able to detect a replay attack. In my >>> opinion client should not reuse the same nonce in multiple requests, >>> we can either mandate client to use different nonce for each request >>> made in a specified window of time or we can mandate client to use >>> "cryptographically strong randomness" to get a random nonce. Please >>> suggest which approach is better in your opinion. >>> >>> @Russ, sure, I am taking a note of adding security consideration >>> about "using 1 octet nonce". Regarding the section 3.1, I added it >>> to highlight risks created by the recommendation made in RFC5019, >>> which suggests that if server does not send a nonce in OCSP response >>> then client should not reject the response just because nonce is >>> missing(https://tools.ietf.org/html/rfc5019#section-4). I know its >>> out of context here but still wanted to re-enforce that there is a >>> risk of replay attack if client chose to accept the response with >>> the missing nonce. >>> >>> Thanks >>> Mohit >>> >>> On Mon, Mar 2, 2020 at 7:47 AM Russ Housley >>> > wrote: >>> A nonce of 1 octet does not really provide the intended protection. >>> Maybe we more could be said in the Security Considerations about the >>> minimum size. Also, why is Section 3.1 indented? >>> >>> Russ >>> >>> >>> >>> On Mar 2, 2020, at 10:20 AM, Mohit Sahni >>> > wrote: >>> >>> Hi All, >>> I started a thread about the issues with the OCSP Nonce extension >>> which was missing the maximum length for the Nonce field in the >>> extension and could create potential security issues with the OCSP >>> responder following RFC 6960. >>> https://mailarchive.ietf.org/arch/msg/spasm/Nh9fD4smTXnF4mhNYmbcULfgBSA/ >>> >>> Based on valuable feedback that I got from the members here, I have >>> written a draft limiting the length of Nonce extension between 1-32 >>> bytes. Here is the link to the >>> draft https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/?include_text=1. >>> Please let me know what you think. >>> >>> Thanks >>> Mohit Sahni >>> > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon Mar 2 14:43: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 04B943A131A for ; Mon, 2 Mar 2020 14:42: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=entrustdatacardcorp.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 6Ju5EWQMAN8C for ; Mon, 2 Mar 2020 14:42:49 -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 012D53A131D for ; Mon, 2 Mar 2020 14:42:48 -0800 (PST) IronPort-SDR: eu33jpascy/b5jgROyJ51Qpw1ruvQYVil8jxe36QQ93uay1gi3r9HXm9UjAk6eKA0NEaAehPPq Qos1vDkageXQ== X-IronPort-AV: E=Sophos;i="5.70,508,1574143200"; d="scan'208";a="68474806" 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; 02 Mar 2020 16:42:48 -0600 Received: from pmspex02.corporate.datacard.com (192.168.211.30) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 2 Mar 2020 16:42:47 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 2 Mar 2020 16:42:47 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VaoGAujPuXGILOf4xHXc0yTGZ6UaWAka0yAmbLX62SKJunfMEshB91U/szngsqzcI2iH5w/lt1eqcdZiKSYtdtfIxCn1deZ66gO940odrIthtSWyeSBWgKKaWTQBbXtxt0erHP/+ia3w2bJVRt1WQqa0/HU6b9QqFmOP53bje62DhYUS6rr/Oz0KHMZ6VCCyLIU/cFqSCT5siSX75A1STMyZR5RyZl4k7u92UecYIkMNwOicyXocHFAD14TntN15rWlqOro50gANuckf6+alFZf8RjZJP/sfOGolggo3xgvEHxxyhbvQoEqSFWuD7Gl+gfB+oIVvfvzKlcgPEZ62nA== 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=GMkS/nwvajwd0pEQ54pOM+2GTu4cl8c+osrz7+Ox5G0=; b=AdRBmXeYvUIjco0xIDTZHEAhD7fl42Z0b7FtLSjvQSDkqu07WMVZ3VxfBLdiz86ZkUv4o0TR3zH0S3emXXbJHBOAqxCFUkGottPuU6IqEprunY6NOpxIqA49yvoOUc6EC/2RwLcqo9qLpI8p+7+jPIYqXgjtUJ6LuQjw2HTquCliu+IWDtQDCtrQVE6LcsYczxdD3KX4qVpSOn9BY0s67ArFOBeN0S9tGZU3oX0Oy7+i+/Vi5vo4nVqTyXXxyG6371CQig96gMT+9LqmQcFy7kxeoLJrscojHfxH/8E4ZMLS6T4xkiwMdvmeonVLoViJAgi8R8aX8JthpBHqKPDecw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GMkS/nwvajwd0pEQ54pOM+2GTu4cl8c+osrz7+Ox5G0=; b=RWp222Ibo9hcc6ciFHIBs1E9LUbeGXhtw/A3C31cuh2bSsQonYHa5wJIOatrgqByvlWSCRFKETcuKI3tkP2DH+o0nDKoN3YH5s1/8B0UutrW39C0DWkrbADnMu12yel6SC7rDlcbTWQ+jOlSKQtLkXcbnxnpH/S1V+9jYVBf9gI= Received: from DM6PR11MB3915.namprd11.prod.outlook.com (2603:10b6:5:19c::11) by DM6PR11MB4706.namprd11.prod.outlook.com (2603:10b6:5:2a5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Mon, 2 Mar 2020 22:42:46 +0000 Received: from DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::942:9c0:9497:beea]) by DM6PR11MB3915.namprd11.prod.outlook.com ([fe80::942:9c0:9497:beea%3]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 22:42:46 +0000 From: Mike Ounsworth To: Tomas Gustavsson , "spasm@ietf.org" Thread-Topic: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce extension Thread-Index: AQHV8No2HASemU9eKk+bIpG2tQL816g11wcAgAAAUQCAAAJjAIAACUcQ Date: Mon, 2 Mar 2020 22:42:46 +0000 Message-ID: References: <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> <64504da8-289e-70d2-4e87-ed140fa0c100@primekey.com> In-Reply-To: <64504da8-289e-70d2-4e87-ed140fa0c100@primekey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a94c2374-e7ae-42bd-236a-08d7befb0780 x-ms-traffictypediagnostic: DM6PR11MB4706: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(376002)(39860400002)(346002)(199004)(189003)(52536014)(8936002)(6506007)(26005)(7696005)(71200400001)(2906002)(186003)(81156014)(66446008)(66476007)(76116006)(66556008)(64756008)(81166006)(966005)(53546011)(478600001)(8676002)(66946007)(316002)(9686003)(110136005)(55016002)(86362001)(33656002)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB4706; H:DM6PR11MB3915.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5m82VWwju/VrgyFdTPZXFRxOyIQodlhYMRJp6Qe5LvR5coaClditGu6BQid2aK2i6teGAW7D9eDl1oTYKwX0Rh5YmkkqzAAeDfrfxLccl1Bsbp4vrCPlOI+dncfhdVGwwK+Pd8McywvR0Ycf4NIX1/0+dgyM3YNR+2tQHtGvI4d0pifyg8RhYwpaAbf8tSaKPH4+xb8kZuTq7A5zOYYM96HLSnzUXD5IZOwqV+fyXAJO4xaBNx2llTrjPDGr7MxY9uOTqQUBfEpbfsUVMaD29yh/Tbt9pumw0dhN0R98zlSWbmwSL3aXWkRkohxQwBE+rAxuTOz+n+BUnjMC5vKjYJtqopOaIFBI/Lui/ZPGD+Z1vNATDI+O0UJmy6TXGY0/KdfOn2GNZwdcMqs7wj76hS+BKePOgsFeqsJTjbONXlY0WJdkZk5zkRVPCvoYFLR+hRAIf79aWQt485vza7PEgl3Qr/S2G1bO/pMMEf46Dq7fLl3wq1o9yTOHIeWOYV5ZAi5KYoYqBjrDi2zCd8RKfQ== x-ms-exchange-antispam-messagedata: arhe4MoXZAghJWA7YKCHLRYNJWaS0diMuckUSzrga93vvCqkyRZgDpjrEJBsTf5lY1T7Wpq6OIWsUvhe+H+2s/gF5JrT3LNVj58DzIK0WU2FTFRis+1FV1i/16V9tKFiIezTZW05mE624UrL1N7zpw== 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-Network-Message-Id: a94c2374-e7ae-42bd-236a-08d7befb0780 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 22:42:46.6952 (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: ymNsUwguEwHAzWV/anJpYmYeUb5z1sioZuIrvzyAaAMOIcRq8rihGVar2KvPFvVbCxR6jdqWh+8qKnVrCbaKGVJ9fmQ3te8tPmsbliQubvijkRuUoYQASKdKRFJoMH6D X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4706 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Mon, 02 Mar 2020 22:42:52 -0000 QXMgSSB1bmRlcnN0YW5kIGl0LCBhIGNsaWVudCB1c2luZyBhIHNob3J0IG9yIGxvdy1lbnRyb3B5 IG5vbmNlIGlzIG9wZW5pbmcgdGhlbXNlbHZlcyB0byByZXBsYXkgYXR0YWNrcywgYnV0IHRoZXJl IGlzIG5vIHJpc2sgdG8gdGhlIHNlcnZlci4gVGhhdCBjb250cmFzdHMgd2l0aCB0b28tbG9uZyBu b25jZXMgLSBEb1MgYW5kIHNpZ25hdHVyZSBmb3JnZXJ5IGF0dGFja3MgLSB3aGVyZSB0aGUgcmlz ayBpcyB0byB0aGUgc2VydmVyLg0KDQpBbiBPQ1NQIHJlc3BvbmRlciAqY291bGQqIGVuZm9yY2Ug YSBtaW5pbXVtIG5vbmNlIGxlbmd0aCBpbiB0aGUgc2FtZSB3YXkgLSBieSByZWplY3RpbmcgcmVx dWVzdHMgdGhhdCBkb24ndCBjb25mb3JtIC0gYnV0IG1heWJlIHRoZXJlIGlzIG5vdCBhIHN0cm9u ZyByZWFzb24gdG8gYmVjYXVzZSAidGhlIGNsaWVudCBpcyBvbmx5IGh1cnRpbmcgaXRzZWxmIiA/ DQoNCi0tLQ0KTWlrZSBPdW5zd29ydGggfCBPZmZpY2U6ICsxICg2MTMpIDI3MC0yODczDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcGFzbSA8c3Bhc20tYm91bmNlc0BpZXRm Lm9yZz4gT24gQmVoYWxmIE9mIFRvbWFzIEd1c3RhdnNzb24NClNlbnQ6IE1hcmNoIDIsIDIwMjAg Mzo1OSBQTQ0KVG86IHNwYXNtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2xhbXBzXSBbRVhURVJO QUxdUmU6IFJGQzY5NjA6IElzc3VlIHdpdGggdGhlIE9DU1AgTm9uY2UgZXh0ZW5zaW9uDQoNCkFz IHRoZSBOb25jZSBpcyBzZXQgYnkgdGhlIGNsaWVudCB0aGUgc2VydmVyIGNhbiBub3QgZW5mb3Jj ZSBhIG1pbmltdW0gbGVuZ3RoLiBUaGUgc2VydmVyIHR5cGljYWxseSBqdXN0IGNvcGllZCB0aGUg bm9uY2UgZnJvbSB0aGUgcmVxdWVzdCBpbnRvIHRoZSByZXNwb25zZS4gTm93IGl0J3MgYWxzbyBj aGVja2luZyB0aGF0IHRoZSBjbGllbnQgZG9lcyBub3Qgc2VuZCBtb3JlIHRoYW4gMzIgYnl0ZXMg YXMgbm9uY2UgYW5kIHdpbGwgZ2l2ZSBhIFVuYXV0aG9yaXplZCByZXNwb25zZSBpZiB0aGUgbm9u Y2Ugc2VudCBieSB0aGUgY2xpZW50IGlzID4zMiBieXRlcy4NCg0KU28sIHRoZXJlIGlzIGEgY2xp ZW50LXNlcnZlciBzZXBhcmF0aW9uLg0KLSBtaW5pbWFsIHNpemUgaXMgYSByZWNvbW1lbmRhdGlv biBmb3IgT0NTUCBjbGllbnRzDQotIG1heGltdW0gc2l6ZSBpcyBhIGxpbWl0IGVuZm9yY2VkIGJ5 IHRoZSBPQ1NQIHJlc3BvbmRlcg0KDQpDaGVlcnMsDQpUb21hcw0KDQpPbiAyMDIwLTAzLTAyIDEz OjUwLCBTYWx6LCBSaWNoIHdyb3RlOg0KPiAgICogSSB3aWxsIGFkZCB0ZXh0IHRvIHN0cm9uZ2x5 IHN1Z2dlc3QgdGhhdCBhIG5vbmNlIGxlbmd0aCBzaG91bGQgYmUNCj4gICAgIGJldHdlZW4gMTYt MzIgb2N0ZXRzIGFuZCBtYWtlIHN1cmUgaW1wbGVtZW50YXRpb25zIGtub3cgdGhlIHJpc2sgb2YN Cj4gICAgIHVzaW5nIHNtYWxsZXIgc2l6ZSBub25jZS4NCj4gDQo+IMKgDQo+IA0KPiBUaGF04oCZ cyBmaW5lIHdpdGggbWUsIHRoYW5rcy4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTcGFzbSBtYWlsaW5nIGxpc3QNCj4gU3Bhc21A aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0K PiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNw YXNtIG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc3Bhc20NCg== From nobody Mon Mar 2 21:16: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 002233A1870; Mon, 2 Mar 2020 21:16:03 -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 gSi5EM1LMcAS; Mon, 2 Mar 2020 21:16:01 -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 232B83A1873; Mon, 2 Mar 2020 21:16:00 -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 0235Fucu003957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 3 Mar 2020 00:15:58 -0500 Date: Mon, 2 Mar 2020 21:15:55 -0800 From: Benjamin Kaduk To: Ryan Sleevi Cc: Russ Housley , SPASM , IETF PKIX Message-ID: <20200303051555.GQ98042@kduck.mit.edu> References: <20200227225404.CA7ADF40714@rfc-editor.org> <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997) 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, 03 Mar 2020 05:16:04 -0000 That does seem like the right higher-order question, but it seems (to me) fairly inevitable that this errata report must be classified as "hold for document update" to give the WG a chance to make a definitive decision, as the original intent remains unclear. -Ben On Fri, Feb 28, 2020 at 01:52:07PM -0500, Ryan Sleevi wrote: > Thanks. You're absolutely right, that was an oversight on my part. > > I think the higher-order question is what the syntax is "meant" to be, as > the use of an illustrative example alone has lead to confusion. Even if a > future revision retroactively 'blesses' ".example.com" as an ambiguity > within 5280, the semantics of that are also ambiguous. > > On Fri, Feb 28, 2020 at 1:39 PM Russ Housley wrote: > > > Ryan: > > > > I see the point you are trying to make, but the exact substitution that > > you propose breaks the sentence that follows. > > > > OLD > > > > DNS name restrictions are expressed as host.example.com. Any DNS > > name that can be constructed by simply adding zero or more labels to > > the left-hand side of the name satisfies the name constraint. For > > example, www.host.example.com would satisfy the constraint but > > host1.example.com would not. > > > > NEW > > > > For DNS names, restrictions MUST use the dNSName syntax in > > Section 4.2.1.6. Any DNS name that can be constructed by simply > > adding zero or more labels to the left-hand side of the name satisfies > > the name constraint. For example, if the constraint contains > > host.example.com, then www.host.example.com would satisfy the > > constraint but host1.example.com would not. > > > > On Feb 28, 2020, at 1:03 PM, Ryan Sleevi wrote: > > > > I've heard word that this may not have gone out to the PKIX list, but I > > did want to pass this along with LAMPS. > > > > As both the current syntax and semantics are ambiguous, judging by > > implementation behaviour, I'm totally appreciative that the suggested > > change might be rejected or might be held for a hypothetical document > > update in the future. > > > > However, I did want to bring to broader attention and document the fact > > that the ambiguity has lead to different levels of guarantees. It was > > recently pointed out to me that Apple adopted the "URI-like" syntax, as > > discussed at > > https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html , > > while as mentioned in the Errata, Go and OpenSSL seem to have adopted the > > "PEBKAC" syntax of assuming it's an encoding error. > > > > Within the Web PKI, tools like Amazon's certlint treats this as an error, > > while tools like ZLint inherit Golang's permissiveness. As a consequence, > > unless the CA applies both checks (which is strongly recommended, due to > > certlint attempting to compile the ASN.1 modules to offer stricter > > validation), it's possible that such certificates might continue to > > proliferate. As discussed within the linked Golang issue, there's > > unfortunately a number of documentation examples that use the leading > > period example, and so RFC 5280 CAs that don't participate exclusively in > > the Web PKI are even more at risk of the varying interpretations. > > > > ---------- Forwarded message --------- > > From: RFC Errata System > > Date: Thu, Feb 27, 2020 at 5:54 PM > > Subject: [Technical Errata Reported] RFC5280 (5997) > > To: , , < > > stephen.farrell@cs.tcd.ie>, , < > > housley@vigilsec.com>, , , , > > , > > Cc: , , > > > > > > The following errata report has been submitted for RFC5280, > > "Internet X.509 Public Key Infrastructure Certificate and Certificate > > Revocation List (CRL) Profile". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5997 > > > > -------------------------------------- > > Type: Technical > > Reported by: Ryan Sleevi > > > > Section: 4.2.1.10 > > > > Original Text > > ------------- > > DNS name restrictions are expressed as host.example.com. Any DNS > > name that can be constructed by simply adding zero or more labels to > > the left-hand side of the name satisfies the name constraint. > > > > Corrected Text > > -------------- > > The syntax of dNSName MUST be as described in Section 4.2.1.6. Any DNS > > name that can be constructed by simply adding zero or more labels to > > the left-hand side of the name satisfies the name constraint. > > > > Notes > > ----- > > Currently, the syntax for a dNSName nameConstraint is left implicit, and > > thus has resulted in ambiguities in encoding and processing that have > > resulted in ineroperability issues. > > > > One interpretation is that the dNSName nameConstraint must be a valid > > "host name" (as discussed in RFC 8499), which is to say must be a > > Fully-Qualified Domain Name in the preferred name syntax. This > > interpretation is supported by Section 4.2.1.6, which explicitly states > > that for the subjectAltName. As 4.2.1.10 does not define an exception to > > this (as discussed in Appendix B), the interpretation, along with the > > existing example, would conclude that this field uses preferred name > > syntax, and that "DNS name" here matches the "host name" interpretation > > from RFC 8499 > > > > A different interpretation is that the dNSName nameConstraint uses the > > modified syntax similar to the URI nameConstraint. That is, it explicitly > > permits a leading period to indicate that one or more labels preceding is > > required in order to satisfy the constraint. This allows subdomains, but > > does not allow the base domain to match. While the language for the DNS > > name constraint makes it clear that a host name with no preceding period > > matches both that host and sub-domains, the existence of a preceding period > > would constraint it to only subdomains. > > > > Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as > > the preferred name syntax does not permit leading periods. Alternatively, > > if the latter interpretation is intended, this section would benefit from > > making that explicit. > > > > This has been a source of interoperability issues, with additional > > information and discussion captured at: > > - https://github.com/golang/go/issues/16347 > > - https://rt.openssl.org/Ticket/Display.html?id=3562 > > > > While "running code" has aligned in being permissive with a leading > > period, implementations have gone and seemingly aligned on a third > > interpretation: > > > > The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the > > exception that it MAY contain a leading period. Any DNS name that can be > > constructed by simply adding zero or more labels to the left-hand side of > > the name, ignoring any leading period, satisfies the name constraint. > > > > This seems to support implementations expecting the first interpretation > > in the certificates they receive, and seeing leading period as an encoding > > mistake, not an explicit desire for the second interpretation. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > > -------------------------------------- > > Title : Internet X.509 Public Key Infrastructure Certificate > > and Certificate Revocation List (CRL) Profile > > Publication Date : May 2008 > > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. > > Housley, W. Polk > > Category : PROPOSED STANDARD > > Source : Public-Key Infrastructure (X.509) > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Mar 3 06:41: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 4E4583A0CAE for ; Tue, 3 Mar 2020 06:41:43 -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 DAO_0XMEYEzZ for ; Tue, 3 Mar 2020 06:41:41 -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 DB1D93A0CAC for ; Tue, 3 Mar 2020 06:41:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2DC66300B49 for ; Tue, 3 Mar 2020 09:41:38 -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 uOSNNYQRp6KW for ; Tue, 3 Mar 2020 09:41:34 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 45EB8300196; Tue, 3 Mar 2020 09:41:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20200303051555.GQ98042@kduck.mit.edu> Date: Tue, 3 Mar 2020 09:41:35 -0500 Cc: Ryan Sleevi , SPASM , IETF PKIX Content-Transfer-Encoding: quoted-printable Message-Id: <40EC4579-6A6A-438A-9E17-DC176D9DDB7E@vigilsec.com> References: <20200227225404.CA7ADF40714@rfc-editor.org> <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com> <20200303051555.GQ98042@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC5280 (5997) 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, 03 Mar 2020 14:41:43 -0000 Ben: I would like to see the revised text put in the errata, and I think Hold = for Doc Update is fine. Russ > On Mar 3, 2020, at 12:15 AM, Benjamin Kaduk wrote: >=20 > That does seem like the right higher-order question, but it seems (to = me) > fairly inevitable that this errata report must be classified as "hold = for > document update" to give the WG a chance to make a definitive = decision, as > the original intent remains unclear. >=20 > -Ben >=20 > On Fri, Feb 28, 2020 at 01:52:07PM -0500, Ryan Sleevi wrote: >> Thanks. You're absolutely right, that was an oversight on my part. >>=20 >> I think the higher-order question is what the syntax is "meant" to = be, as >> the use of an illustrative example alone has lead to confusion. Even = if a >> future revision retroactively 'blesses' ".example.com" as an = ambiguity >> within 5280, the semantics of that are also ambiguous. >>=20 >> On Fri, Feb 28, 2020 at 1:39 PM Russ Housley = wrote: >>=20 >>> Ryan: >>>=20 >>> I see the point you are trying to make, but the exact substitution = that >>> you propose breaks the sentence that follows. >>>=20 >>> OLD >>>=20 >>> DNS name restrictions are expressed as host.example.com. Any DNS >>> name that can be constructed by simply adding zero or more labels = to >>> the left-hand side of the name satisfies the name constraint. For >>> example, www.host.example.com would satisfy the constraint but >>> host1.example.com would not. >>>=20 >>> NEW >>>=20 >>> For DNS names, restrictions MUST use the dNSName syntax in >>> Section 4.2.1.6. Any DNS name that can be constructed by simply >>> adding zero or more labels to the left-hand side of the name = satisfies >>> the name constraint. For example, if the constraint contains >>> host.example.com, then www.host.example.com would satisfy the >>> constraint but host1.example.com would not. >>>=20 >>> On Feb 28, 2020, at 1:03 PM, Ryan Sleevi = wrote: >>>=20 >>> I've heard word that this may not have gone out to the PKIX list, = but I >>> did want to pass this along with LAMPS. >>>=20 >>> As both the current syntax and semantics are ambiguous, judging by >>> implementation behaviour, I'm totally appreciative that the = suggested >>> change might be rejected or might be held for a hypothetical = document >>> update in the future. >>>=20 >>> However, I did want to bring to broader attention and document the = fact >>> that the ambiguity has lead to different levels of guarantees. It = was >>> recently pointed out to me that Apple adopted the "URI-like" syntax, = as >>> discussed at >>> = https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html , >>> while as mentioned in the Errata, Go and OpenSSL seem to have = adopted the >>> "PEBKAC" syntax of assuming it's an encoding error. >>>=20 >>> Within the Web PKI, tools like Amazon's certlint treats this as an = error, >>> while tools like ZLint inherit Golang's permissiveness. As a = consequence, >>> unless the CA applies both checks (which is strongly recommended, = due to >>> certlint attempting to compile the ASN.1 modules to offer stricter >>> validation), it's possible that such certificates might continue to >>> proliferate. As discussed within the linked Golang issue, there's >>> unfortunately a number of documentation examples that use the = leading >>> period example, and so RFC 5280 CAs that don't participate = exclusively in >>> the Web PKI are even more at risk of the varying interpretations. >>>=20 >>> ---------- Forwarded message --------- >>> From: RFC Errata System >>> Date: Thu, Feb 27, 2020 at 5:54 PM >>> Subject: [Technical Errata Reported] RFC5280 (5997) >>> To: , , < >>> stephen.farrell@cs.tcd.ie>, , < >>> housley@vigilsec.com>, , , = , >>> , >>> Cc: , , = >>>=20 >>>=20 >>> The following errata report has been submitted for RFC5280, >>> "Internet X.509 Public Key Infrastructure Certificate and = Certificate >>> Revocation List (CRL) Profile". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid5997 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Ryan Sleevi >>>=20 >>> Section: 4.2.1.10 >>>=20 >>> Original Text >>> ------------- >>> DNS name restrictions are expressed as host.example.com. Any DNS >>> name that can be constructed by simply adding zero or more labels to >>> the left-hand side of the name satisfies the name constraint. >>>=20 >>> Corrected Text >>> -------------- >>> The syntax of dNSName MUST be as described in Section 4.2.1.6. Any = DNS >>> name that can be constructed by simply adding zero or more labels to >>> the left-hand side of the name satisfies the name constraint. >>>=20 >>> Notes >>> ----- >>> Currently, the syntax for a dNSName nameConstraint is left implicit, = and >>> thus has resulted in ambiguities in encoding and processing that = have >>> resulted in ineroperability issues. >>>=20 >>> One interpretation is that the dNSName nameConstraint must be a = valid >>> "host name" (as discussed in RFC 8499), which is to say must be a >>> Fully-Qualified Domain Name in the preferred name syntax. This >>> interpretation is supported by Section 4.2.1.6, which explicitly = states >>> that for the subjectAltName. As 4.2.1.10 does not define an = exception to >>> this (as discussed in Appendix B), the interpretation, along with = the >>> existing example, would conclude that this field uses preferred name >>> syntax, and that "DNS name" here matches the "host name" = interpretation >>> from RFC 8499 >>>=20 >>> A different interpretation is that the dNSName nameConstraint uses = the >>> modified syntax similar to the URI nameConstraint. That is, it = explicitly >>> permits a leading period to indicate that one or more labels = preceding is >>> required in order to satisfy the constraint. This allows subdomains, = but >>> does not allow the base domain to match. While the language for the = DNS >>> name constraint makes it clear that a host name with no preceding = period >>> matches both that host and sub-domains, the existence of a preceding = period >>> would constraint it to only subdomains. >>>=20 >>> Aligning with Section 4.2.1.6 would prohibit the latter = interpretation, as >>> the preferred name syntax does not permit leading periods. = Alternatively, >>> if the latter interpretation is intended, this section would benefit = from >>> making that explicit. >>>=20 >>> This has been a source of interoperability issues, with additional >>> information and discussion captured at: >>> - https://github.com/golang/go/issues/16347 >>> - https://rt.openssl.org/Ticket/Display.html?id=3D3562 >>>=20 >>> While "running code" has aligned in being permissive with a leading >>> period, implementations have gone and seemingly aligned on a third >>> interpretation: >>>=20 >>> The syntax of a dNSName MUST be as described in Section 4.2.1.6, = with the >>> exception that it MAY contain a leading period. Any DNS name that = can be >>> constructed by simply adding zero or more labels to the left-hand = side of >>> the name, ignoring any leading period, satisfies the name = constraint. >>>=20 >>> This seems to support implementations expecting the first = interpretation >>> in the certificates they receive, and seeing leading period as an = encoding >>> mistake, not an explicit desire for the second interpretation. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC5280 (draft-ietf-pkix-rfc3280bis-11) >>> -------------------------------------- >>> Title : Internet X.509 Public Key Infrastructure = Certificate >>> and Certificate Revocation List (CRL) Profile >>> Publication Date : May 2008 >>> Author(s) : D. Cooper, S. Santesson, S. Farrell, S. = Boeyen, R. >>> Housley, W. Polk >>> Category : PROPOSED STANDARD >>> Source : Public-Key Infrastructure (X.509) >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>>=20 >>>=20 >>>=20 >=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Mar 3 13:08:56 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 54ED63A09A0; Tue, 3 Mar 2020 13:08:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158326973332.7569.2493568631195786547@ietfa.amsl.com> Date: Tue, 03 Mar 2020 13:08:53 -0800 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-5480-ku-clarifications-02: (with COMMENT) 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: Tue, 03 Mar 2020 21:08:54 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lamps-5480-ku-clarifications-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If further clarifications can be made based on the latest email from the Gen-ART reviewer, that would be good. From nobody Tue Mar 3 13:09: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 4FA1A3A09A7; Tue, 3 Mar 2020 13:09:49 -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=pass (2048-bit key) header.d=cooperw.in header.b=tdgTZbXR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fmGzxI3i Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPWw6cX4ArBO; Tue, 3 Mar 2020 13:09:47 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A1C3A09A8; Tue, 3 Mar 2020 13:09:47 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id BA4317A9; Tue, 3 Mar 2020 16:09:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 03 Mar 2020 16:09:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T X8zZ2l//fEuUPBxL2P3BLjQTTisgx+SdtHn+itMrf4=; b=tdgTZbXRlaxKxVNQ+ iHE8eOnLVMGgr/n7o61wKFt3ecpzHDNUq9YXmMZwbbTjMJD9n2V2CGju9dGGf90t 62WQntr1L069qulYUY5/WNU/9z4zWg0OcpIa/cuu3ZbOT6Lg5mqQmcn6OPduNBTf lPk4GGNBOuaLIAODXEzUCY8OOyldLlT/1FqjOtxwEYw6R5nBfqz5YH6sWdwh/s6r 8B19zub2SoPrZS9sqv8WqYBG3PJ6sK3HGJ//c7q9oeyUg3uxpH+OA7/NnCabN1al vI4mYB29TwRF5Vo/zl8YNlip4rhpxkN8yZ5v8fA6HgzeVn2DYOZko+LFAKn3mgZD lgqeA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=TX8zZ2l//fEuUPBxL2P3BLjQTTisgx+SdtHn+itMr f4=; b=fmGzxI3i4CYLe0iYBrbb75PHQrlj782jKN06q6z/zoOzFbEcvuOUsmHzl Bse/HwEG6tXIdUrJLfnTDSLvXs6o/mClDga9oCjClRJESVH8Rnl+qP51chqMWEGv uDCnth8aegNTkKmd7Vrtgohy+yrmIiCvqDMpwcGP5eX2kImWaWL79xc008fDY0V7 f5w9XoqyuMmEa2zbfDQKFNqlGukUC/1Jrm5bXJV+/6oyIohdZPRyPzbqKeI9MX0x G+/whiWV1uLRFxwVOzoherp9lCsPD9wiyL+oPxJOxM+LuUD51zQ/O44TEON9t9bW RQpWeeGaX7jHzIuxLL1AmV26Z1XKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtiedgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdektdenucevlhhu shhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestg hoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id A655C3280060; Tue, 3 Mar 2020 16:09:42 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <878skjcso5.fsf@hobgoblin.ariadne.com> Date: Tue, 3 Mar 2020 16:09:40 -0500 Cc: Sean Turner , draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, gen-art@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54001CEE-1D17-46CB-9314-D9AF45452D63@cooperw.in> References: <878skjcso5.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01 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, 03 Mar 2020 21:09:49 -0000 Dale, thanks for your reviews. Sean, thanks for your responses. I = entered a No Objection ballot. If Dale=E2=80=99s questions can be = clarified for non-expert readers, I think that would be good. Alissa > On Mar 1, 2020, at 11:00 PM, Dale R. Worley = wrote: >=20 > Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points > occur to me: >=20 > 1. Introduction >=20 > This document corrects this omission, by updating Section 3 of > [RFC5480] to make it clear that neither keyEncipherment nor the > dataEncipherment key usage bits are set for key agreement = algorithms. >=20 > I think it would be more accurate to say something like "neither ... = are > set in certificates that specify key agreement algorithms" -- usage = bits > are logically a component of a certificate rather than a feature of an > algorithm. >=20 > But it's unclear to me whether id-ecPublicKey is only used in key > agreement certificates. RFC 5480 states that if the cert uses id-ecDH > or id-ecMQV and provides keyUsage, then keyAgreement must be set. So > it's clear that certs with id-ecDH or id-ecMQV are key agreement = certs. > But RFC 5480 says that if the cert lists id-ecPublicKey, then > keyAgreement is optional. That suggests to me that some certs can use > id-ecPublicKey without being key agreement certs. In turn, section 1 = of > this I-D suggests the I-D is not intended to apply to those certs, but > section 3 seems to apply to them anyway. >=20 > To try to distill it to one sentence: Can id-ecPublicKey appear in > certs that are not for key agreement, and if so, are keyEncipherment = and > dataEncipherment allowed in the keyUsage of those certs? >=20 > 3. Updates to Section 3 >=20 > If the keyUsage extension is present in a certificate that indicates > in SubjectPublicKeyInfo, then following values MUST NOT be present: > ---^ >=20 > Is "id-ecPublicKey" missing here? >=20 > If the keyUsage extension is present in a certificate that indicates > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > values also MUST NOT be present: >=20 > Is it a fact that all certificates with these three algorithms are > certificates for key agreement? If so, it would be nice to state that > either in section 3 or section 1, to show how section 3 is connected > with "for key agreement algorithms" in section 1. Otherwise, the > connection between the two requires information that is stated > elsewhere. >=20 > Dale >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Mar 4 05:34:36 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 8C99D3A0F67; Wed, 4 Mar 2020 05:34: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: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158332886347.29408.3541381589000101486@ietfa.amsl.com> Date: Wed, 04 Mar 2020 05:34:23 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-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: Wed, 04 Mar 2020 13:34: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 : CMP Updates Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-updates-01.txt Pages : 16 Date : 2020-03-04 Abstract: This document contains a set of updates to the base syntax of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue and the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities. 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cmp-updates-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 Wed Mar 4 05:34:45 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 46D723A0F58; Wed, 4 Mar 2020 05:34:36 -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: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158332887618.29390.9418767249024750854@ietfa.amsl.com> Date: Wed, 04 Mar 2020 05:34:36 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-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: Wed, 04 Mar 2020 13:34:44 -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-01.txt Pages : 72 Date : 2020-03-04 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 uses 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 also 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-lightweight-cmp-profile-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 Wed Mar 4 09:23: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 BE9EB3A1307 for ; Wed, 4 Mar 2020 09:23:47 -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 t-_xX-_JTqX1 for ; Wed, 4 Mar 2020 09:23:46 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 09B1C3A130C for ; Wed, 4 Mar 2020 09:23:46 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id q18so2381957qki.10 for ; Wed, 04 Mar 2020 09:23:45 -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=6s+uopJy5xYMt3/5XA/ouS7zTcQoP6dtRzY5HlqH08w=; b=XG0G6xapZfZ6hLhVQbgyx89mL6et8tMC0/OcyKoL9HFBFmZUze0/ktrwvkVXbqzqud oWLEVur+Vtls3vp2iAAjcqMjShrbXGy9P9nXwRiCvYENNN0BNOmsrJ1/4619Irxtx0D/ 0if1i2y+K6+EPxfXwMVujtabc1wS+3gwuf/DU= 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=6s+uopJy5xYMt3/5XA/ouS7zTcQoP6dtRzY5HlqH08w=; b=PWKPdkun7K9T/B1oHeKfvToulRKpa3AtzK7qUrCibpwsrUgWxan25ZDQJGzupDDJMT 9JSbMl2nmUz16pZM8nxCmu1tgUXTQ14evai6aBy1h6biXvX0wSmnaBG895ZiXp+DH267 CXiTvZy2KXWXw3OsjHBwljeNiVfvdXHGZ4a493M9DAuiCdJSH5qD+6gfkn998TDhKvfH MctxJAWHUyzXt2mOshIFY43HLPQvZ83EjuXCGMzZybeH37ZsT1epSnHXx2r5w6xr2ZI9 OsdLlJzdcehAEfICFMmDA2D7mhNReaZ+NrRzDKQcXYSeCVVgQUr8Od9MWFX2OGjfeTJK 8eYg== X-Gm-Message-State: ANhLgQ2inEgPUM7hclyzc9FH9kivxDtH9KsiPz4+yYgDdOEyIQEU8HX9 JTmqkioUbiusbkVXNoGXaHbSUg== X-Google-Smtp-Source: ADFU+vuuMRklV3ACmi9o8I5ivOtkPXhc4fF/70bHWqxgt8G669GYo/o/qfOuJDqe+XW49ahTt0E4aQ== X-Received: by 2002:a37:4351:: with SMTP id q78mr3951498qka.409.1583342625158; Wed, 04 Mar 2020 09:23:45 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id t3sm12605661qkt.114.2020.03.04.09.23.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2020 09:23:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <54001CEE-1D17-46CB-9314-D9AF45452D63@cooperw.in> Date: Wed, 4 Mar 2020 12:23:43 -0500 Cc: draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, gen-art@ietf.org, LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <6426AD1D-5D15-4BAC-814C-0F7626AA804A@sn3rd.com> References: <878skjcso5.fsf@hobgoblin.ariadne.com> <54001CEE-1D17-46CB-9314-D9AF45452D63@cooperw.in> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01 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 Mar 2020 17:23:48 -0000 > On Mar 3, 2020, at 16:09, Alissa Cooper wrote: >=20 > Dale, thanks for your reviews. Sean, thanks for your responses. I = entered a No Objection ballot. If Dale=E2=80=99s questions can be = clarified for non-expert readers, I think that would be good. >=20 > Alissa >=20 >=20 >> On Mar 1, 2020, at 11:00 PM, Dale R. Worley = wrote: >>=20 >> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points >> occur to me: >>=20 >> 1. Introduction >>=20 >> This document corrects this omission, by updating Section 3 of >> [RFC5480] to make it clear that neither keyEncipherment nor the >> dataEncipherment key usage bits are set for key agreement = algorithms. >>=20 >> I think it would be more accurate to say something like "neither ... = are >> set in certificates that specify key agreement algorithms" -- usage = bits >> are logically a component of a certificate rather than a feature of = an >> algorithm. >>=20 >> But it's unclear to me whether id-ecPublicKey is only used in key >> agreement certificates. RFC 5480 states that if the cert uses = id-ecDH >> or id-ecMQV and provides keyUsage, then keyAgreement must be set. So >> it's clear that certs with id-ecDH or id-ecMQV are key agreement = certs. >> But RFC 5480 says that if the cert lists id-ecPublicKey, then >> keyAgreement is optional. That suggests to me that some certs can = use >> id-ecPublicKey without being key agreement certs. In turn, section 1 = of >> this I-D suggests the I-D is not intended to apply to those certs, = but >> section 3 seems to apply to them anyway. >>=20 >> To try to distill it to one sentence: Can id-ecPublicKey appear in >> certs that are not for key agreement, and if so, are keyEncipherment = and >> dataEncipherment allowed in the keyUsage of those certs? >>=20 >> 3. Updates to Section 3 >>=20 >> If the keyUsage extension is present in a certificate that indicates >> in SubjectPublicKeyInfo, then following values MUST NOT be present: >> ---^ >>=20 >> Is "id-ecPublicKey" missing here? Yes - The OPSDIR review noted my took quick to submit. It=E2=80=99s = fixed in this version: = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >> If the keyUsage extension is present in a certificate that indicates >> id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following >> values also MUST NOT be present: >>=20 >> Is it a fact that all certificates with these three algorithms are >> certificates for key agreement? If so, it would be nice to state = that >> either in section 3 or section 1, to show how section 3 is connected >> with "for key agreement algorithms" in section 1. Otherwise, the >> connection between the two requires information that is stated >> elsewhere. To address this, I ended up making the following tweaks in s1: This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms defined therein. The additions are to be made to the end of Section 3. So, there=E2=80=99s a link from 5480 s3 where the three algorithms are = defined to this document=E2=80=99s s3. spt >> Dale >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 From nobody Thu Mar 5 10:35: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 CA65D3A093B; Thu, 5 Mar 2020 10:35:47 -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_DNSWL_BLOCKED=0.001, 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 xOCDa6oPMjwD; Thu, 5 Mar 2020 10:35:46 -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 18A8F3A0937; Thu, 5 Mar 2020 10:35:45 -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 025IZWXo009738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 5 Mar 2020 13:35:35 -0500 Date: Thu, 5 Mar 2020 10:35:32 -0800 From: Benjamin Kaduk To: Sean Turner Cc: "Dale R. Worley" , draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, gen-art@ietf.org, LAMPS WG Message-ID: <20200305183532.GU98042@kduck.mit.edu> References: <878skjcso5.fsf@hobgoblin.ariadne.com> <54001CEE-1D17-46CB-9314-D9AF45452D63@cooperw.in> <6426AD1D-5D15-4BAC-814C-0F7626AA804A@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6426AD1D-5D15-4BAC-814C-0F7626AA804A@sn3rd.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01 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 Mar 2020 18:35:48 -0000 On Wed, Mar 04, 2020 at 12:23:43PM -0500, Sean Turner wrote: > > > > On Mar 3, 2020, at 16:09, Alissa Cooper wrote: > > > > Dale, thanks for your reviews. Sean, thanks for your responses. I entered a No Objection ballot. If Dale’s questions can be clarified for non-expert readers, I think that would be good. > > > > Alissa > > > > > >> On Mar 1, 2020, at 11:00 PM, Dale R. Worley wrote: > >> > >> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points > >> occur to me: > >> > >> 1. Introduction > >> > >> This document corrects this omission, by updating Section 3 of > >> [RFC5480] to make it clear that neither keyEncipherment nor the > >> dataEncipherment key usage bits are set for key agreement algorithms. > >> > >> I think it would be more accurate to say something like "neither ... are > >> set in certificates that specify key agreement algorithms" -- usage bits > >> are logically a component of a certificate rather than a feature of an > >> algorithm. > >> > >> But it's unclear to me whether id-ecPublicKey is only used in key > >> agreement certificates. RFC 5480 states that if the cert uses id-ecDH > >> or id-ecMQV and provides keyUsage, then keyAgreement must be set. So > >> it's clear that certs with id-ecDH or id-ecMQV are key agreement certs. > >> But RFC 5480 says that if the cert lists id-ecPublicKey, then > >> keyAgreement is optional. That suggests to me that some certs can use > >> id-ecPublicKey without being key agreement certs. In turn, section 1 of > >> this I-D suggests the I-D is not intended to apply to those certs, but > >> section 3 seems to apply to them anyway. > >> > >> To try to distill it to one sentence: Can id-ecPublicKey appear in > >> certs that are not for key agreement, and if so, are keyEncipherment and > >> dataEncipherment allowed in the keyUsage of those certs? > >> > >> 3. Updates to Section 3 > >> > >> If the keyUsage extension is present in a certificate that indicates > >> in SubjectPublicKeyInfo, then following values MUST NOT be present: > >> ---^ > >> > >> Is "id-ecPublicKey" missing here? > > Yes - The OPSDIR review noted my took quick to submit. It’s fixed in this version: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ > > >> If the keyUsage extension is present in a certificate that indicates > >> id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > >> values also MUST NOT be present: > >> > >> Is it a fact that all certificates with these three algorithms are > >> certificates for key agreement? If so, it would be nice to state that > >> either in section 3 or section 1, to show how section 3 is connected > >> with "for key agreement algorithms" in section 1. Otherwise, the > >> connection between the two requires information that is stated > >> elsewhere. > > To address this, I ended up making the following tweaks in s1: > > This document corrects this omission, by updating Section 3 of > [RFC5480] to make it clear that neither keyEncipherment nor the > dataEncipherment key usage bits are set for key agreement algorithms > defined therein. The additions are to be made to the end of > Section 3. > > So, there’s a link from 5480 s3 where the three algorithms are defined to this document’s s3. I don't think that link fully closes the question of whether id-ecPublicKey is defined to be a"key agreement algorithm" or not. -Ben From nobody Thu Mar 5 12:37: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 CA83B3A0B7C for ; Thu, 5 Mar 2020 12:36:52 -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=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 xck7WXnpo6uu for ; Thu, 5 Mar 2020 12:36: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 348143A0B7D for ; Thu, 5 Mar 2020 12:36:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 124F3300B4C for ; Thu, 5 Mar 2020 15:29: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 qKaRbSnHJ8eQ for ; Thu, 5 Mar 2020 15:29:46 -0500 (EST) Received: from [192.168.1.159] (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 3B967300AEF; Thu, 5 Mar 2020 15:29:46 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20200305183532.GU98042@kduck.mit.edu> Date: Thu, 5 Mar 2020 15:29:47 -0500 Cc: Sean Turner , "Dale R. Worley" , draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, IETF Gen-ART , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <85D6F268-E675-4573-A7BD-275975DF441E@vigilsec.com> References: <878skjcso5.fsf@hobgoblin.ariadne.com> <54001CEE-1D17-46CB-9314-D9AF45452D63@cooperw.in> <6426AD1D-5D15-4BAC-814C-0F7626AA804A@sn3rd.com> <20200305183532.GU98042@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01 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 Mar 2020 20:36:53 -0000 > On Mar 5, 2020, at 1:35 PM, Benjamin Kaduk wrote: >=20 > On Wed, Mar 04, 2020 at 12:23:43PM -0500, Sean Turner wrote: >>=20 >>=20 >>> On Mar 3, 2020, at 16:09, Alissa Cooper wrote: >>>=20 >>> Dale, thanks for your reviews. Sean, thanks for your responses. I = entered a No Objection ballot. If Dale=E2=80=99s questions can be = clarified for non-expert readers, I think that would be good. >>>=20 >>> Alissa >>>=20 >>>=20 >>>> On Mar 1, 2020, at 11:00 PM, Dale R. Worley = wrote: >>>>=20 >>>> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points >>>> occur to me: >>>>=20 >>>> 1. Introduction >>>>=20 >>>> This document corrects this omission, by updating Section 3 of >>>> [RFC5480] to make it clear that neither keyEncipherment nor the >>>> dataEncipherment key usage bits are set for key agreement = algorithms. >>>>=20 >>>> I think it would be more accurate to say something like "neither = ... are >>>> set in certificates that specify key agreement algorithms" -- usage = bits >>>> are logically a component of a certificate rather than a feature of = an >>>> algorithm. >>>>=20 >>>> But it's unclear to me whether id-ecPublicKey is only used in key >>>> agreement certificates. RFC 5480 states that if the cert uses = id-ecDH >>>> or id-ecMQV and provides keyUsage, then keyAgreement must be set. = So >>>> it's clear that certs with id-ecDH or id-ecMQV are key agreement = certs. >>>> But RFC 5480 says that if the cert lists id-ecPublicKey, then >>>> keyAgreement is optional. That suggests to me that some certs can = use >>>> id-ecPublicKey without being key agreement certs. In turn, section = 1 of >>>> this I-D suggests the I-D is not intended to apply to those certs, = but >>>> section 3 seems to apply to them anyway. >>>>=20 >>>> To try to distill it to one sentence: Can id-ecPublicKey appear in >>>> certs that are not for key agreement, and if so, are = keyEncipherment and >>>> dataEncipherment allowed in the keyUsage of those certs? >>>>=20 >>>> 3. Updates to Section 3 >>>>=20 >>>> If the keyUsage extension is present in a certificate that = indicates >>>> in SubjectPublicKeyInfo, then following values MUST NOT be present: >>>> ---^ >>>>=20 >>>> Is "id-ecPublicKey" missing here? >>=20 >> Yes - The OPSDIR review noted my took quick to submit. It=E2=80=99s = fixed in this version: >>=20 >> = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >>=20 >>>> If the keyUsage extension is present in a certificate that = indicates >>>> id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following >>>> values also MUST NOT be present: >>>>=20 >>>> Is it a fact that all certificates with these three algorithms are >>>> certificates for key agreement? If so, it would be nice to state = that >>>> either in section 3 or section 1, to show how section 3 is = connected >>>> with "for key agreement algorithms" in section 1. Otherwise, the >>>> connection between the two requires information that is stated >>>> elsewhere. >>=20 >> To address this, I ended up making the following tweaks in s1: >>=20 >> This document corrects this omission, by updating Section 3 of >> [RFC5480] to make it clear that neither keyEncipherment nor the >> dataEncipherment key usage bits are set for key agreement algorithms >> defined therein. The additions are to be made to the end of >> Section 3. >>=20 >> So, there=E2=80=99s a link from 5480 s3 where the three algorithms = are defined to this document=E2=80=99s s3. >=20 > I don't think that link fully closes the question of whether = id-ecPublicKey > is defined to be a"key agreement algorithm" or not. That identifier is used for key agreement and signature. The key usage = extension can restrict it to one or the other if desired. The point of = this update is that it is not ever a key encipherment or data = encipherment algorithm. Russ From nobody Thu Mar 5 17:32:10 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 DFAFA3A0CAF; Thu, 5 Mar 2020 17:32:04 -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: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158345832482.14562.5303312467111631831@ietfa.amsl.com> Date: Thu, 05 Mar 2020 17:32:04 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-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: Fri, 06 Mar 2020 01:32:05 -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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-01.txt Pages : 11 Date : 2020-03-05 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to have interoperability when RFC7030 has been extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints, providing a way to do this in an upward compatible way. This document fixes some syntactical errors in ASN.1 that was presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-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 Thu Mar 5 17:36:28 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 85B5E3A104A; Thu, 5 Mar 2020 17:36:26 -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: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158345858645.14723.3002052789783805901@ietfa.amsl.com> Date: Thu, 05 Mar 2020 17:36:26 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc7030est-clarify-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: Fri, 06 Mar 2020 01:36:27 -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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 Authors : Michael Richardson Thomas Werner Wei Pan Filename : draft-ietf-lamps-rfc7030est-clarify-02.txt Pages : 11 Date : 2020-03-05 Abstract: This document updates RFC7030: Enrollment over Secure Transport (EST) to resolve some errata that was reported, and which has proven to have interoperability when RFC7030 has been extended. This document deprecates the specification of "Content-Transfer- Encoding" headers for EST endpoints, providing a way to do this in an upward compatible way. This document fixes some syntactical errors in ASN.1 that was presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc7030est-clarify-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 Thu Mar 5 17:49: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 977153A108A for ; Thu, 5 Mar 2020 17:49:45 -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 8dBMQEt93mNB for ; Thu, 5 Mar 2020 17:49:42 -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 073F93A108E for ; Thu, 5 Mar 2020 17:49:41 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F3483897F; Thu, 5 Mar 2020 20:48:32 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 918E510E8; Thu, 5 Mar 2020 20:49:40 -0500 (EST) From: Michael Richardson To: spasm@ietf.org CC: max pritikin , martin.furuhed@nexusgroup.com, shahid.raza@ri.se In-Reply-To: <158345858645.14723.3002052789783805901@ietfa.amsl.com> References: <158345858645.14723.3002052789783805901@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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: [lamps] next steps for draft-ietf-lamps-rfc7030est-clarify-02.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: Fri, 06 Mar 2020 01:49:46 -0000 --=-=-= Content-Type: text/plain see below for a longer discussion internet-drafts@ietf.org wrote: > 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 : Clarification of Enrollment over Secure Transport (EST): transfer encodings and ASN.1 > Authors : Michael Richardson > Thomas Werner > Wei Pan > Filename : draft-ietf-lamps-rfc7030est-clarify-02.txt > Pages : 11 > Date : 2020-03-05 > Abstract: > This document updates RFC7030: Enrollment over Secure Transport (EST) > to resolve some errata that was reported, and which has proven to > have interoperability when RFC7030 has been extended. > This document deprecates the specification of "Content-Transfer- > Encoding" headers for EST endpoints, providing a way to do this in an > upward compatible way. This document fixes some syntactical errors > in ASN.1 that was presented. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-02 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-02 A useful diff from the previous version is available at: https://www.ietf.org/rfcdiff?url1=draft-ietf-lamps-rfc7030est-clarify-00&url2=draft-ietf-lamps-rfc7030est-clarify-02 I goofed some markdown on -01, and obliterated the IANA Considerations header. This version fills in the text for the errata-5108, literally taking what was suggested, as I don't think that there really any discussion. There are now two more errata filed since we started this process: a) https://www.rfc-editor.org/errata/eid5904 is dealt with in this update, as it's about Content-Transfer-Encoding. Is Justin Crawford on this list? How can I reach out to this person? Neither of his options fits what industry has actually implemented, which is base64 encoded objects, without a Content-Transfer-Encoding. b) https://www.rfc-editor.org/errata/eid5926 asks to have the Examples updates. I think that we could do that in this document. I would prefer to take examples from deployed products, and I've CC'ed some people who could probably generate that. c) https://www.rfc-editor.org/errata/eid5779 points out the extra before ";", which should be tolerated, but not required. This could updated with (b) above, I think. If the WG would like to let the authors know if we should do (b) and (c). I believe that (a) requires no action other than marking the errata as duplicated, or fixed in this document. Should reference to errata be informative or normative? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5hrDQACgkQgItw+93Q 3WUd9QgAtuAxciBnDgwXEoreRTBaG1YXq8UO4bl3+nH2fWVvqlhL/tHNZ4WIHHJ9 FVZIQo8/rJxwBU3jVDGonV0f3RgHQSUpK0EsnzrxSYrDW8YOHp1un66Vq93YJeq/ hs+/VLRtuahQMLRzUnazgYUGZyuE4C2VapopAiXCp+TrnQRM1e8st3lmAfR3BWLa a4JYLClKSd11TCxGuxOSzWdFbEqpDfL2a6iw/9rMsqHCYAZl+0MTxCdNdI/gjBA7 BboOimLqhClp9aIMwEr6Oks3LhjtkuPjAIaWuUouN88CS3uovl4uexOq4R8gvpTT Dl+t5yUrbOy47qiYYPf4O6YgwHSL/A== =p/tx -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Mar 7 16:16:09 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 31B503A0D1F; Sat, 7 Mar 2020 00:14:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Klaas Wierenga via Datatracker To: Cc: draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, spasm@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158356889211.18182.3861551159795927490@ietfa.amsl.com> Reply-To: Klaas Wierenga Date: Sat, 07 Mar 2020 00:14:52 -0800 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-5480-ku-clarifications-02 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: Sat, 07 Mar 2020 08:14:52 -0000 X-List-Received-Date: Sat, 07 Mar 2020 08:14:52 -0000 Reviewer: Klaas Wierenga Review result: Ready Nice, clear and short document. From nobody Sun Mar 8 14:30:11 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 ED7143A0538 for ; Sun, 8 Mar 2020 14:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.637 X-Spam-Level: X-Spam-Status: No, score=0.637 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, MALFORMED_FREEMAIL=1.713, MISSING_HEADERS=1.021, 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 8bWY5dq5wQK7 for ; Sun, 8 Mar 2020 14:30:07 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 ED7683A0474 for ; Sun, 8 Mar 2020 14:30:06 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id f21so3087271iol.6 for ; Sun, 08 Mar 2020 14:30:06 -0700 (PDT) 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:cc; bh=5vPTsdTlMQJib1CU1E4ej6eCHMj6PI8jQP/PD0Q+pUI=; b=bc1jx153NqyXJRLZTgsdEPAwOuWfFqjSHk3ROk4Wu2oB4R5JRIQQrQwxhIWSg6uqlJ OyB4DaFCR4gNLLZW2rqf+up9aMmiOvyYjuUBMQxuzkZc2iNUuLyvPqO7F2jMmT2ZCVGx ZnrBLsT5aILe2Y2aIbSnMwzrlJ8V1JUtqCx2T2gABNeKuha/neRz7EhlIhjgeDIRumFg Y4eeKzE6eYldJCIzCthCo93nSe9YM5PSvHtJNlV88LAGHtWoz2anMbCGAzGEVzbE9dD8 Gg5oSVBV7sq36M9+vojphNqAW5kCkFO7sEp7uAB6xks501UNVKLod1HHcEzKAYDsNl/j R88A== 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:cc; bh=5vPTsdTlMQJib1CU1E4ej6eCHMj6PI8jQP/PD0Q+pUI=; b=udVHWXYu8oXtXG01nrVGFgyW9xsFy/ZueKdlTujjl/1GbSdbEJ/BUG1+I8GFs0ft79 qzf8t9xWO/bulWKNb8WeInhYOtyjCwX7quHTDINwR2CovPjOzJwIwXT4CgFbK515pNUE 9SSu8ZwHZKlrm8itUcXNbPBeT6W2pmqGclQmhQog9HfrUY6i3ZJPW4FEMZj72G2IK1/D DZLkMrLNJ2DqPSlyptZ0yGHx/i9/Vp6XsO5vk1qaALP/WO4dIBwfdikaElvs5MHY2oZA vpSbkGhfYnulXLIYYdcuRl0SeDgsaEB7utq+Gf3CH+Heo0N3D00kICoDp4wys3Yy95wR Yi2A== X-Gm-Message-State: ANhLgQ3tA+kf8mxvbVIdaOipxuJ3tyz6jocXnK1WVbNnJtQhrmCAIyxD dv0szGWmroDiVoFIXJCIq2i7xZmsMUE22691haeiXayo X-Google-Smtp-Source: ADFU+vv4t1kqpl/ZJdAocAaaLay+JpnVgOaf6SwFGiudDnTKyKkm5HGyfWDzZ2WC007RSR4utsdqHnvMiu6Ah5YcYUA= X-Received: by 2002:a05:6638:3ba:: with SMTP id z26mr12037477jap.68.1583703005869; Sun, 08 Mar 2020 14:30:05 -0700 (PDT) MIME-Version: 1.0 References: <96FC0A60-3642-4BF3-8237-E204F1F37994@akamai.com> <64504da8-289e-70d2-4e87-ed140fa0c100@primekey.com> In-Reply-To: From: Mohit Sahni Date: Sun, 8 Mar 2020 14:29:55 -0700 Message-ID: Cc: "spasm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000183eb505a05e9758" Archived-At: Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP 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: Sun, 08 Mar 2020 21:30:09 -0000 --000000000000183eb505a05e9758 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I have upload a new version of the draft based on your valuable feedback. Here are the main changes: 1. Added a section under security considerations about importance of using a cryptographically strong randomness that is freshly generated for the nonce value and about the importance of using a Nonce of larger lengths to avoid replays. 2. Modified the section 2.1 to explicitly mention that server should reject a ocsp request with nonce of more than 32 bytes as malformedRequest error. 3. Added the following requirements in section 2.1 a) The newer clients should use nonce of at-least 16 bytes and the minimum length of 1 is specified only for the purpose of backward compatibility with clients following RFC 6960. b) The Nonce MUST be generated using a cryptographically strong pseudorandom number generator. I hope I have taken care of all the comments, please review the new version of draft at below mentioned URL and let me know any further feedback. https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ Regards, Mohit On Mon, Mar 2, 2020 at 2:42 PM Mike Ounsworth < Mike.Ounsworth@entrustdatacard.com> wrote: > As I understand it, a client using a short or low-entropy nonce is openin= g > themselves to replay attacks, but there is no risk to the server. That > contrasts with too-long nonces - DoS and signature forgery attacks - wher= e > the risk is to the server. > > An OCSP responder *could* enforce a minimum nonce length in the same way = - > by rejecting requests that don't conform - but maybe there is not a stron= g > reason to because "the client is only hurting itself" ? > > --- > Mike Ounsworth | Office: +1 (613) 270-2873 > > -----Original Message----- > From: Spasm On Behalf Of Tomas Gustavsson > Sent: March 2, 2020 3:59 PM > To: spasm@ietf.org > Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce > extension > > As the Nonce is set by the client the server can not enforce a minimum > length. The server typically just copied the nonce from the request into > the response. Now it's also checking that the client does not send more > than 32 bytes as nonce and will give a Unauthorized response if the nonce > sent by the client is >32 bytes. > > So, there is a client-server separation. > - minimal size is a recommendation for OCSP clients > - maximum size is a limit enforced by the OCSP responder > > Cheers, > Tomas > > On 2020-03-02 13:50, Salz, Rich wrote: > > * I will add text to strongly suggest that a nonce length should be > > between 16-32 octets and make sure implementations know the risk of > > using smaller size nonce. > > > > > > > > That=E2=80=99s fine with me, thanks. > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --000000000000183eb505a05e9758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
I have upload=C2=A0a new version of= the draft based on your valuable feedback. Here are the main changes:=C2= =A0
1. Added a section under security considerations about import= ance of using a cryptographically=C2=A0 strong randomness that is freshly g= enerated for the nonce value and about the importance of using a Nonce of l= arger=C2=A0lengths to avoid=C2=A0replays.
2. Modified the section= 2.1 to explicitly=C2=A0mention that server should reject a ocsp request wi= th nonce of more than 32 bytes as malformedRequest error.=C2=A0
3= . Added the following requirements in section 2.1
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 a) The newer clients should use nonce of at-least=C2=A016 byt= es and the minimum length=C2=A0of 1 is specified only for the purpose of ba= ckward compatibility with clients following RFC 6960.=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) The Nonce MUST be generated using a crypt= ographically strong=C2=A0pseudorandom number generator.=C2=A0=C2=A0

I hope I have taken care of all the comments, please revi= ew the new version of draft at below mentioned URL and=C2=A0let me know any= further feedback.=C2=A0

Regards,
Mohit=C2=A0
On Mon, Mar 2, 2020 at 2:42 PM Mike Ounsworth <Mike.Ounsworth@entrustdatacard.co= m> wrote:
As I understand it, a client using a short or low-entropy nonce is opening= themselves to replay attacks, but there is no risk to the server. That con= trasts with too-long nonces - DoS and signature forgery attacks - where the= risk is to the server.

An OCSP responder *could* enforce a minimum nonce length in the same way - = by rejecting requests that don't conform - but maybe there is not a str= ong reason to because "the client is only hurting itself" ?

---
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Spasm <spasm-bounces@ietf.org> On Behalf Of Tomas Gustavsson
Sent: March 2, 2020 3:59 PM
To: spasm@ietf.org<= br> Subject: Re: [lamps] [EXTERNAL]Re: RFC6960: Issue with the OCSP Nonce exten= sion

As the Nonce is set by the client the server can not enforce a minimum leng= th. The server typically just copied the nonce from the request into the re= sponse. Now it's also checking that the client does not send more than = 32 bytes as nonce and will give a Unauthorized response if the nonce sent b= y the client is >32 bytes.

So, there is a client-server separation.
- minimal size is a recommendation for OCSP clients
- maximum size is a limit enforced by the OCSP responder

Cheers,
Tomas

On 2020-03-02 13:50, Salz, Rich wrote:
>=C2=A0 =C2=A0* I will add text to strongly suggest that a nonce length = should be
>=C2=A0 =C2=A0 =C2=A0between 16-32 octets and make sure implementations = know the risk of
>=C2=A0 =C2=A0 =C2=A0using smaller size nonce.
>
> =C2=A0
>
> That=E2=80=99s fine with me, thanks.
>
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org=
> https://www.ietf.org/mailman/listinfo/spasm
>

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--000000000000183eb505a05e9758-- From nobody Mon Mar 9 08:58:47 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 AE76A3A12BB; Mon, 9 Mar 2020 08:58:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158376952262.5608.9742103984595025685@ietfa.amsl.com> Date: Mon, 09 Mar 2020 08:58:42 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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, 09 Mar 2020 15:58:43 -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 : Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection Author : Russ Housley Filename : draft-ietf-lamps-cms-update-alg-id-protect-01.txt Pages : 8 Date : 2020-03-09 Abstract: This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers are adequately protected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-protect-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-update-alg-id-protect-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 Mar 9 09:02: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 0004D3A12ED for ; Mon, 9 Mar 2020 09:02:15 -0700 (PDT) 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 VpZFa2TokBoV for ; Mon, 9 Mar 2020 09:02:14 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494903A12E8 for ; Mon, 9 Mar 2020 09:02:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DDB013005D5 for ; Mon, 9 Mar 2020 12:02:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z3q_X0QYgNrz for ; Mon, 9 Mar 2020 12:02:10 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 8621C3004C0 for ; Mon, 9 Mar 2020 12:02:10 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 9 Mar 2020 12:02:12 -0400 References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <158376952262.5608.9742103984595025685@ietfa.amsl.com> Message-Id: <35C34180-8890-4A7B-85C5-419D4D9586C8@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Mon, 09 Mar 2020 16:02:16 -0000 I updated the section ong timestamps based on some comments from an = implementer. Russ > On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection > Author : Russ Housley > Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt > Pages : 8 > Date : 2020-03-09 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers are > adequately protected. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 From nobody Mon Mar 9 09:43: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 BDC193A1120 for ; Mon, 9 Mar 2020 09:43:06 -0700 (PDT) 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 SKRfKnOg3-Vv for ; Mon, 9 Mar 2020 09:43:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6313F3A0C42 for ; Mon, 9 Mar 2020 09:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B8919300AFB for ; Mon, 9 Mar 2020 12:43:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id By69JpYg3p-G for ; Mon, 9 Mar 2020 12:43:00 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id D9BA0300A91; Mon, 9 Mar 2020 12:42:59 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_17EAD894-2014-4B58-8796-FE6DE08FA722"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 9 Mar 2020 12:43:00 -0400 In-Reply-To: <901.1583459380@localhost> Cc: LAMPS WG To: Michael Richardson References: <158345858645.14723.3002052789783805901@ietfa.amsl.com> <901.1583459380@localhost> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] next steps for draft-ietf-lamps-rfc7030est-clarify-02.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 Mar 2020 16:43:07 -0000 --Apple-Mail=_17EAD894-2014-4B58-8796-FE6DE08FA722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael: RFC 8713 references errata in the Informational References section. Russ > On Mar 5, 2020, at 8:49 PM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > see below for a longer discussion >=20 > internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 >> Title : Clarification of Enrollment over Secure Transport = (EST): transfer encodings and ASN.1 >> Authors : Michael Richardson >> Thomas Werner >> Wei Pan >> Filename : draft-ietf-lamps-rfc7030est-clarify-02.txt >> Pages : 11 >> Date : 2020-03-05 >=20 >> Abstract: >> This document updates RFC7030: Enrollment over Secure Transport (EST) >> to resolve some errata that was reported, and which has proven to >> have interoperability when RFC7030 has been extended. >=20 >> This document deprecates the specification of "Content-Transfer- >> Encoding" headers for EST endpoints, providing a way to do this in an >> upward compatible way. This document fixes some syntactical errors >> in ASN.1 that was presented. >=20 >=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ >=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-lamps-rfc7030est-clarify-02 >> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc7030est-clarify-= 02 >=20 > A useful diff from the previous version is available at: >=20 > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-lamps-rfc7030est-clarify-00= &url2=3Ddraft-ietf-lamps-rfc7030est-clarify-02 >=20 > I goofed some markdown on -01, and obliterated the IANA Considerations = header. >=20 > This version fills in the text for the errata-5108, literally taking = what was > suggested, as I don't think that there really any discussion. >=20 > There are now two more errata filed since we started this process: > a) https://www.rfc-editor.org/errata/eid5904 >=20 > is dealt with in this update, as it's about = Content-Transfer-Encoding. > Is Justin Crawford on this list? How can I reach out to this person? > Neither of his options fits what industry has actually implemented, = which is > base64 encoded objects, without a Content-Transfer-Encoding. >=20 > b) https://www.rfc-editor.org/errata/eid5926 >=20 > asks to have the Examples updates. I think that we could do that in = this > document. I would prefer to take examples from deployed products, and = I've > CC'ed some people who could probably generate that. >=20 > c) https://www.rfc-editor.org/errata/eid5779 >=20 > points out the extra before ";", which should be tolerated, but = not > required. This could updated with (b) above, I think. >=20 > If the WG would like to let the authors know if we should do (b) and = (c). > I believe that (a) requires no action other than marking the errata as > duplicated, or fixed in this document. >=20 > Should reference to errata be informative or normative? >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 --Apple-Mail=_17EAD894-2014-4B58-8796-FE6DE08FA722 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 iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXmZyFAAKCRCK5O7Q9ZwR ywg1AKChhNrPISij+V4GDdj9r9jbk81o/ACfQrEyU5pO2A7XURRaC8YDWt3lj+A= =Xqhy -----END PGP SIGNATURE----- --Apple-Mail=_17EAD894-2014-4B58-8796-FE6DE08FA722-- From nobody Mon Mar 9 13:34: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 78E973A0CA5 for ; Mon, 9 Mar 2020 13:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EVxr9kQ4BGtJ for ; Mon, 9 Mar 2020 13:34:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9A63A0AA3 for ; Mon, 9 Mar 2020 13:34:07 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B17E3818F for ; Mon, 9 Mar 2020 16:32:55 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4AD739F9 for ; Mon, 9 Mar 2020 16:34:06 -0400 (EDT) From: Michael Richardson To: LAMPS WG In-Reply-To: References: <158345858645.14723.3002052789783805901@ietfa.amsl.com> <901.1583459380@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] next steps for draft-ietf-lamps-rfc7030est-clarify-02.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 Mar 2020 20:34:11 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > RFC 8713 references errata in the Informational References section. Thank you, that's what I've done. >> There are now two more errata filed since we started this process: >> a) https://www.rfc-editor.org/errata/eid5904 >> >> is dealt with in this update, as it's about Content-Transfer-Encoding. >> Is Justin Crawford on this list? How can I reach out to this person? >> Neither of his options fits what industry has actually implemented, which is >> base64 encoded objects, without a Content-Transfer-Encoding. >> >> b) https://www.rfc-editor.org/errata/eid5926 >> >> asks to have the Examples updates. I think that we could do that in this >> document. I would prefer to take examples from deployed products, and I've >> CC'ed some people who could probably generate that. I propose to mark these errata as being dealt with by this update as well by adding examples. >> c) https://www.rfc-editor.org/errata/eid5779 >> >> points out the extra before ";", which should be tolerated, but not >> required. This could updated with (b) above, I think. We could repeat the example and fix it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5mqD4ACgkQgItw+93Q 3WXIrgf/YWc6ptcCRuGZqJQNBIOrA7iy1IeF15LmQ9KIHHHBWqXov92aZnPjhAWl 0P69Ctc1QzSVGu52s8InJx3VMK2IxU2EtdRlL/h775rhBberVKzs1KYZ5TN2Uea3 jjpOK+0IxJE6OmSt4q0sJMZOceGMySGhQKcACJgQuQmEJ2+9nuLZJseandLYVY43 Bf+0j8rPlkv51USQN3B6TH0eSeNIuFjARW2dUFsXGkefrQhAA7GMOegxiR/NpI21 jVQO9d/yJYFkG9HRax9WyZFgKbcu7rz6+fgfz1/5uitbsa0VwD+O1ZjPvV3RNs5g 0KprAZo3/fDPPyqbAW2N8uSW8bIBBg== =utvQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Mar 10 06:46: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 CA29A3A1319 for ; Tue, 10 Mar 2020 06:46:47 -0700 (PDT) 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 nuLM9g_vDKaW for ; Tue, 10 Mar 2020 06:46:46 -0700 (PDT) Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 2436C3A1310 for ; Tue, 10 Mar 2020 06:46:46 -0700 (PDT) Received: by mail-qk1-x742.google.com with SMTP id f3so12738176qkh.1 for ; Tue, 10 Mar 2020 06:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pRNLTti4BZ0dbxQyF4WxUl6UXHaHLqUhnC/VdTesePg=; b=grQic/5MpPmId6PD7UBmXx+kRipOPUqfB6HSvSPvo2xyjNAsih4AODDDBqAW6s/86z VyBS/njbXKxO4dQT3AeKxgqjTMA8k5fqpxBW5ZvmiE1puZgVoZrF3vlojaPGL5Dh00TY WZ8NHATJtVsIgiqkRV+gMZP5WrsJGEiTXE6rM= 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=pRNLTti4BZ0dbxQyF4WxUl6UXHaHLqUhnC/VdTesePg=; b=KV3daUT6zN3c2nDHzTwaPhGC/DbdJafZSviHzGIZ8XjpjZ4CUtG1Jfoapk7fxFOPfe z7c8efc+wRiLH4QOreB/+vxoxgI5RKSG+dvS237CcVmrHaQnmoOVZ3h/raACsUoeOVKd PR/dRAXmvkoP1+lp6OhkSRq+0J0TCCtsy8uuJKzMTc1WkPy+29OL4qV/N/UPYJzG6UTi uvLfSm8rrCuaanDMH3XidS8EtXkCBxPnWyyt+TEBTBXa/XaCvN6HDD4hcAo1yN31LII5 HXtHyg/kZn5utiiCUURCCI5BTUeP6Pi+3bVcTTzh8X5vOKHovA4oUBkHrOTk07ktU/nM 4Htg== X-Gm-Message-State: ANhLgQ1BIwCuC67nsIfuYMooLPC7eJPuhWE4gTfvdN8uj0KExOYkNiNf QaaJhXtqF/f3UbCWD0f+NNadBA== X-Google-Smtp-Source: ADFU+vu2dVD++U0QPTTqedJKvz9dzR68AKgo37cltfKYUZSWqsRm0/T1dl1knsaAmgslpKBsz3mHfA== X-Received: by 2002:ae9:de06:: with SMTP id s6mr19487569qkf.34.1583848005105; Tue, 10 Mar 2020 06:46:45 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id n74sm1634936qke.125.2020.03.10.06.46.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 06:46:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Sean Turner In-Reply-To: <158316902472.27462.8228261234382311611@ietfa.amsl.com> Date: Tue, 10 Mar 2020 09:46:42 -0400 Cc: The IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley Content-Transfer-Encoding: quoted-printable Message-Id: References: <158316902472.27462.8228261234382311611@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-5480-ku-clarifications-02: (with COMMENT) 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 Mar 2020 13:46:48 -0000 Ben, Sorry - I totally missed this one. > On Mar 2, 2020, at 12:10 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lamps-5480-ku-clarifications-02: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm somewhat amenable to the genart reviewer's concerns that we are > implicitly asserting restrictions in RFC 5480 usage by describing the > algorithms defined by 5480 as "key agreement algorithms"; RFC 5480 = does > not seem to use that terminology to refer to id-ecPublicKey. >=20 > Section 1 >=20 > Cryptography. As part of these semantics, it defines what > combinations are permissible for the values of the key usage > extensions [RFC5280]. [RFC5480] specifies 7 of the 9 values; it >=20 > nit: IMO, "key usage extensions" would mean both keyUsage and > extendedKeyUsage, but this document considers only the identified bits > in the original keyUsage extension, and thus the singular "extension" > would be more appropriate. Ah keen eye. Yes this is just for the key usage extension and not the = EKU extension. I will fix that up. > Section 4 >=20 > What are the considerations that apply to implementations that follow > RFC 5480 but not this document, e.g., existing implementations that > allow keyEncipherment and/or dataEncipherment? Specifically, if we = are > forbidding their usage, is it because there are vulnerabilities to = doing > so? It seems like we should mention them here. These additions are about clarifying an omission in the standard. As far = I know, there aren=E2=80=99t any vulnerabilities to setting them. spt From nobody Tue Mar 10 08:38: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 096FD3A1132 for ; Tue, 10 Mar 2020 08:38:21 -0700 (PDT) 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 Z0db_3fzij0l for ; Tue, 10 Mar 2020 08:38:19 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9272C3A1124 for ; Tue, 10 Mar 2020 08:38:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2A542300A44 for ; Tue, 10 Mar 2020 11:38:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id z6ffMdgNQgYS for ; Tue, 10 Mar 2020 11:38:15 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id AF25C300B06 for ; Tue, 10 Mar 2020 11:38:15 -0400 (EDT) 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.11\)) Date: Tue, 10 Mar 2020 11:38:17 -0400 References: To: LAMPS WG In-Reply-To: Message-Id: <48B86E75-15AD-4DE6-8E7B-BA6B4AEB8FBA@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] LAMPS Agenda 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 Mar 2020 15:38:21 -0000 Here is the LAMPS WG Agenda: https://datatracker.ietf.org/meeting/107/materials/agenda-107-lamps-00 Russ and Tim = = = = = = = = LAMPS WG Agenda at IETF 107 in Vancouver 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-5480-ku-clarifications (Sean) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) b) draft-ietf-lamps-cms-update-alg-id-protect (Russ) c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) d) draft-ietf-lamps-cmp-updates (Henk) e) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) 4) Wrap Up From nobody Thu Mar 12 09:53: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 764F83A0DDB for ; Thu, 12 Mar 2020 09:53:48 -0700 (PDT) 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 34erRLD7ERBB for ; Thu, 12 Mar 2020 09:53:47 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 E02F33A0DBE for ; Thu, 12 Mar 2020 09:53:46 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id l14so6134288ilj.8 for ; Thu, 12 Mar 2020 09:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lKu8axRfByWSW9L1UNP4/DUEcdLexrnG1/asXawzVFQ=; b=O14DLzmHjjezXSKeihRBbV9MF/hprnREYuMsQUtJOG+TYjMaaS8kRbNQfkp3PFogmA nxKwZWyKtTakbxJ7S95NjJp0JF7Kgzn4OgiL/tQcgXA95WKfVhKbS8bqh0xb6N9663KL VyoYRsTnSexpHjtWiEmRc46EXAKc3tptrALYEPlAEdDH7ikCpKz5IwiXSnD+05n6fagI yDNKlAvyJ498cduSJUF6nB8Vun5qge1djoO5XbQ48FngiwoZ7FMzpB8m6MvAN2Gx0/B+ mo0R+LryHyrqDJvS1wcTR6LNi6TquapefQGBsYKxwEvL5/nNK8gqN5PJ7gkX80reKvDs Hl+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lKu8axRfByWSW9L1UNP4/DUEcdLexrnG1/asXawzVFQ=; b=pkIk6OTXz2hxWo1rqOdkKl9euXyjN6RPZ1tQYzXz3xInhcjctOxA6pGfBl3YxbOBcy TOtnQV1ptwkSKewp3qiSusUMWxaSkJMwHY4W8RdfEusWFF3nh7PYgWd976JGqqkLVUxK xsWu/8s+Yf8pR42PYPMKcVunI7zQ4fqG1dIi6lVmGoshR8vA6sP5478bobfGx32YRYyI yATStbfWKZ7R040LTZIUdqjbxua3EXTHtTfuj52LzW8UAX1zqLXgknNx/LAmAUuLO63e TIgKJ6CT5sub+LfU5+vJkUDYgB8wy+kN2m842uMMk4kle5CAt6ce0YI1lF7lQenHeppG alng== X-Gm-Message-State: ANhLgQ0ZMSPnwpUpLDULUAPax8qI6ircVD9I6gIULn7w9ds0yB9CaSkB oC58uR0g1vDqmJOmSz3YMIAppsqCQvCCeHRqeFRKpGTD X-Google-Smtp-Source: ADFU+vuiFYLibZHZSRe0v8Pt8jJOMg1Yq3cae2D4Ag/kOIqVygYmKdIlX7XMD7xwm7tTLUqNU0oRh44cIsieImftGdo= X-Received: by 2002:a92:187:: with SMTP id 129mr8749803ilb.24.1584032025706; Thu, 12 Mar 2020 09:53:45 -0700 (PDT) MIME-Version: 1.0 From: Mohit Sahni Date: Thu, 12 Mar 2020 09:53:35 -0700 Message-ID: To: spasm@ietf.org Content-Type: multipart/alternative; boundary="000000000000348e9a05a0ab3288" Archived-At: Subject: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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, 12 Mar 2020 16:53:53 -0000 --000000000000348e9a05a0ab3288 Content-Type: text/plain; charset="UTF-8" Hi All, I recently proposed a draft for properly defining the OCSP nonce extension, specifically the length of the extension. Based on feedback I got from the LAPMS WG members, I have updated the draft (draft-msahni-lamps-ocsp-nonce-01) at https://datatracker.ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ . I will request the WG members to kindly adopt the draft as an active working group document and get it published. Thanks Mohit --000000000000348e9a05a0ab3288 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,
I recently proposed a draft for properly d= efining the OCSP nonce extension, specifically the length of the extension.= =C2=A0Based on feedback I got from the LAPMS=C2=A0WG members, I have update= d the draft (draft-msahni-lamps-ocsp-nonce-01) at=C2=A0https://datatracker= .ietf.org/doc/draft-msahni-lamps-ocsp-nonce/=C2=A0.=C2=A0
I will request the WG members to kindly adopt=C2=A0the draft as= an active working group document and get it published.

Thanks
Mohit=C2=A0
--000000000000348e9a05a0ab3288-- From nobody Thu Mar 12 11:40: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 B1ECD3A0F75 for ; Thu, 12 Mar 2020 11:40:54 -0700 (PDT) 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 CWJZMoEb-yOQ for ; Thu, 12 Mar 2020 11:40:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7F93A0F65 for ; Thu, 12 Mar 2020 11:40:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F0C5300B0B for ; Thu, 12 Mar 2020 14:40:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DP3lbgMuobj4 for ; Thu, 12 Mar 2020 14:40:48 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id B89E6300A02; Thu, 12 Mar 2020 14:40:48 -0400 (EDT) From: Russ Housley Message-Id: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A307A502-0A5B-47C2-865A-1936A854CF62" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 12 Mar 2020 14:40:50 -0400 In-Reply-To: Cc: spasm@ietf.org To: Mohit Sahni References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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, 12 Mar 2020 18:40:55 -0000 --Apple-Mail=_A307A502-0A5B-47C2-865A-1936A854CF62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mohit: I have two concerns with the document. First, the Abstract and Introduction talk about "the updated format". = This is not really what is happening. The nonce in RFC 6960 is an OCTET = STRING, and the nonce with this update is still an OCTET STRING. I = think it would be better to describe this a clarification on the sizes = of nonces that should be supported by an OCSP implementation. Second, updates to an RFC usually have OLD and NEW text. In this case = the NEW text needs to be provided for three sections. -- Section 4.4.1: The NEW text is essentially Section 2.1 of your = Internet-Draft. -- Appendix B.1: I do not see a specification in this module for Nonce. = It should be there. So, your document should add a line: Nonce ::=3D OCTET STRING(SIZE(1..32)) -- Appendix B.2: The re-ocsp-nonce EXTENSION definition should be = updated: OLD: re-ocsp-nonce EXTENSION ::=3D { SYNTAX OCTET STRING IDENTIFIED BY id-pkix-ocsp-nonce } NEW: Nonce ::=3D OCTET STRING(SIZE(1..32)) re-ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce IDENTIFIED BY id-pkix-ocsp-nonce } Russ > On Mar 12, 2020, at 12:53 PM, Mohit Sahni = wrote: >=20 > Hi All, > I recently proposed a draft for properly defining the OCSP nonce = extension, specifically the length of the extension. Based on feedback I = got from the LAPMS WG members, I have updated the draft = (draft-msahni-lamps-ocsp-nonce-01) at = https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ = .=20 >=20 > I will request the WG members to kindly adopt the draft as an active = working group document and get it published. >=20 > Thanks > Mohit=20 --Apple-Mail=_A307A502-0A5B-47C2-865A-1936A854CF62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Mohit:

I have two = concerns with the document.

First, = the Abstract and Introduction talk about "the updated format". =  This is not really what is happening.  The nonce in RFC 6960 = is an OCTET STRING, and the nonce with this update is still an OCTET = STRING.  I think it would be better to describe this a = clarification on the sizes of nonces that should be supported by an OCSP = implementation.

Second, updates to = an RFC usually have OLD and NEW text.  In this case the NEW text = needs to be provided for three sections.

-- Section 4.4.1:  The NEW text is = essentially Section 2.1 of your Internet-Draft.

-- Appendix B.1:  I do not see a = specification in this module for Nonce.  It should be there. =  So, your document should add a line:

      Nonce ::=3D OCTET = STRING(SIZE(1..32))

-- Appendix B.2: = The re-ocsp-nonce EXTENSION definition should be updated:

OLD:

re-ocsp-nonce EXTENSION ::=3D { SYNTAX OCTET = STRING IDENTIFIED
            =                   BY = id-pkix-ocsp-nonce }

NEW:

Nonce = ::=3D OCTET STRING(SIZE(1..32))

re-ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce = IDENTIFIED
              =                 BY = id-pkix-ocsp-nonce }


Russ


On Mar = 12, 2020, at 12:53 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:

Hi All,
I recently proposed a = draft for properly defining the OCSP nonce extension, specifically the = length of the extension. Based on feedback I got from the = LAPMS WG members, I have updated the draft = (draft-msahni-lamps-ocsp-nonce-01) at https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce= / . 

I will request the WG members to kindly adopt the draft = as an active working group document and get it published.

Thanks
Mohit 

= --Apple-Mail=_A307A502-0A5B-47C2-865A-1936A854CF62-- From nobody Thu Mar 12 11:45: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 EFE203A0F88 for ; Thu, 12 Mar 2020 11:45:04 -0700 (PDT) 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 wvQ0lO9Ycjmy for ; Thu, 12 Mar 2020 11:45:03 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 EBF283A0F34 for ; Thu, 12 Mar 2020 11:45:02 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id w9so6754497iob.12 for ; Thu, 12 Mar 2020 11:45:02 -0700 (PDT) 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=6dPkwCfRg2G6ilpu4SPETTXINYi6uz1+Qh1QgiTYNp0=; b=ZyIFJ6OuXoY4A1W0PCNXChPZS346U7wxDcS3rJmon6+LkFbgsqTnx957U+/lkR5cit q6WtWUUkMgXjfwEWn+ksGD7HDN5FBedfXR7WiRtTKiHLhjGH2CVj/Bay1D3XbQnK3EY+ E6BhZdxqI3tLr6Jn44sazSOb3yzmiavfNvnM0tTXlOzBk6anyqZTUjWl2AKVf1QKHSsq NssuGA0YoF7Ukp2Uv8THY2KTIEZ+cfLGLn5s04+JMwN4SVEY0DWTzIACqttOsRyxomy2 9mETnJ1bxWhfeL9gr/UdKP6Xfzx4dkF0awH8SsLvrsqPDJcJX5+FaeRrhgZdjkQGCtTG CBqQ== 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=6dPkwCfRg2G6ilpu4SPETTXINYi6uz1+Qh1QgiTYNp0=; b=FbLFoyTrPFDCRyZmX7i6sAR2AW2porWZvXDZki+W8RkIBDGYcdxnpuzf+/Gr4DKk3n rzFkHSTGZnXU9cRMVQ9i/WstCLJJUDrKsYotL5K87u8XMJuNjee3Y/plGJOuHOVfq/ql yJuvXeF8UA6ftDLwSp2qvwXwDhtDwEplCY/p3Igai3VZr5acVcx/4xEcfsgB98btJBm7 KM60Q8ppsDx620qQNx2sJgr/HQpwv55WLwcPqLUJq+bsC2QT5NuuhDJGMEkeyFfdgiNT gqukyKe7ZEN+ga05UsXiwsb9O4T9wWmOhQ3IywenJ22j88p0aG75qXo93EeX6vuKOMt9 xQvA== X-Gm-Message-State: ANhLgQ1C9V7ajE8+zLiTiQPYHUmxYAufG4E08RcVJdX1qH1LWzvd2/YE zGoQdn+00fWgvMDYti2Ja432+wY70hzzvEWSx3nayQ== X-Google-Smtp-Source: ADFU+vvjf3E89ul0USyA1XVAsIhGRHodviIwmF9kZiXa3YtC2vo9Xb8tAPtl+QFZenNozsjO/h+x+zVbsfFjvKVad58= X-Received: by 2002:a02:cb1c:: with SMTP id j28mr9433451jap.63.1584038701879; Thu, 12 Mar 2020 11:45:01 -0700 (PDT) MIME-Version: 1.0 References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> In-Reply-To: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> From: Mohit Sahni Date: Thu, 12 Mar 2020 11:44:50 -0700 Message-ID: To: Russ Housley Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="00000000000022d52905a0acc0b6" Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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, 12 Mar 2020 18:45:05 -0000 --00000000000022d52905a0acc0b6 Content-Type: text/plain; charset="UTF-8" Hi Russ, Thanks for the comments, I will make these changes and update the draft. -Mohit On Thu, Mar 12, 2020 at 11:40 AM Russ Housley wrote: > > Mohit: > > I have two concerns with the document. > > First, the Abstract and Introduction talk about "the updated format". > This is not really what is happening. The nonce in RFC 6960 is an OCTET > STRING, and the nonce with this update is still an OCTET STRING. I think > it would be better to describe this a clarification on the sizes of nonces > that should be supported by an OCSP implementation. > > Second, updates to an RFC usually have OLD and NEW text. In this case the > NEW text needs to be provided for three sections. > > -- Section 4.4.1: The NEW text is essentially Section 2.1 of your > Internet-Draft. > > -- Appendix B.1: I do not see a specification in this module for Nonce. > It should be there. So, your document should add a line: > > Nonce ::= OCTET STRING(SIZE(1..32)) > > -- Appendix B.2: The re-ocsp-nonce EXTENSION definition should be updated: > > OLD: > > re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED > BY id-pkix-ocsp-nonce } > > NEW: > > Nonce ::= OCTET STRING(SIZE(1..32)) > > re-ocsp-nonce EXTENSION ::= { SYNTAX Nonce IDENTIFIED > BY id-pkix-ocsp-nonce } > > > Russ > > > On Mar 12, 2020, at 12:53 PM, Mohit Sahni wrote: > > Hi All, > I recently proposed a draft for properly defining the OCSP nonce > extension, specifically the length of the extension. Based on feedback I > got from the LAPMS WG members, I have updated the draft > (draft-msahni-lamps-ocsp-nonce-01) at > https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ > . > > I will request the WG members to kindly adopt the draft as an active > working group document and get it published. > > Thanks > Mohit > > > --00000000000022d52905a0acc0b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,
Thanks for the comments, I will make these ch= anges and update the draft.=C2=A0

-Mohit=C2=A0

On Thu, Mar 12, 2020 at 11:40 AM Russ Housley <housley@vigilsec.com> wrote:

Mohit:

I have two concerns with the d= ocument.

First, the Abstract and Introduction talk= about "the updated format".=C2=A0 This is not really what is hap= pening.=C2=A0 The nonce in RFC 6960 is an OCTET STRING, and the nonce with = this update is still an OCTET STRING.=C2=A0 I think it would be better to d= escribe this a clarification on the sizes of nonces that should be supporte= d by an OCSP implementation.

Second, updates to an= RFC usually have OLD and NEW text.=C2=A0 In this case the NEW text needs t= o be provided for three sections.

-- Section 4.4.1= : =C2=A0The NEW text is essentially Section 2.1 of your Internet-Draft.

-- Appendix B.1: =C2=A0I do not see a specification i= n this module for Nonce.=C2=A0 It should be there.=C2=A0 So, your document = should add a line:

=C2=A0 =C2=A0 =C2=A0 Nonce ::= =3D OCTET STRING(SIZE(1..32))

-- Appendix B.2: The= re-ocsp-nonce EXTENSION definition should be updated:

=
OLD:

re-ocsp-nonce EXTENSION ::=3D { SYN= TAX OCTET STRING IDENTIFIED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BY id= -pkix-ocsp-nonce }

NEW:

<= div>Nonce ::=3D OCTET STRING(SIZE(1..32))

re-ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce IDENTIFIED
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 BY id-pkix-ocsp-nonce }

=

Russ


On Mar 12, 2020, at 12:53 PM, Mohit Sahni <mohit06jan@gmail.com> w= rote:

Hi All,
I recently proposed a = draft for properly defining the OCSP nonce extension, specifically the leng= th of the extension.=C2=A0Based on feedback I got from the LAPMS=C2=A0WG me= mbers, I have updated the draft (draft-msahni-lamps-ocsp-nonce-01) at=C2=A0= https://datatracker..ietf.org/doc/draft-msahni-lamps-ocs= p-nonce/=C2=A0.=C2=A0

I will request the WG me= mbers to kindly adopt=C2=A0the draft as an active working group document an= d get it published.

Thanks
Mohit=C2=A0

--00000000000022d52905a0acc0b6-- From nobody Fri Mar 13 10:39: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 A6B583A017E for ; Fri, 13 Mar 2020 10:39:36 -0700 (PDT) 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 eP54wZcCo7lK for ; Fri, 13 Mar 2020 10:39:35 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 E12773A0143 for ; Fri, 13 Mar 2020 10:39:34 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id v38so988458qvf.6 for ; Fri, 13 Mar 2020 10:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YSKp0BKI8W5qkMLab30dG990wXA7e7tHDopyOyhn00I=; b=LjW9dSqvv2N/KdftQfyCpmMlMWE22K/W4O2DL7ESoRoBSjoIij6YuY2VKzHmDniBVK zV6pV1RNVpCJNIAzyPn6IovpoyujmB7OnW80xKCm1WxNohIk/7sbJt/Ja0uQi8D3MqbM /XSDKS7Xdw2ZK0mQ7i130VTeGo96dK6lY/w5g= 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=YSKp0BKI8W5qkMLab30dG990wXA7e7tHDopyOyhn00I=; b=st7QERXPHEdmUyN2tSN8eWFDDK70hOg9qqVfKGSipnckSrOo9/Xa8PHzUUuyW9Zqb9 d3hY17546vQEKhoQuLP0ZnG7BCXXiPc056uTCVa6UMJoBIFZmP6GichSQ0XpBHBd5CLV wNAtu5wu95i6WoTpiGBdXPg7RJOsM7qQInrXbAW1zJNMpcnnVscSPRCJfPm5rkooxvrW AI5V3QzYiaDEi12hjJ8kZZwl1W3GKiLrpehK/aY7Mga7SacThxF0IGv35YMayb6CYB8q BeoV0WGYTvcHNIhhwkCHPkUAXIRjtwEkSgERJhsbGdy394hfFp6kRwaUITwem5kSFv9h QZFQ== X-Gm-Message-State: ANhLgQ13p0x5pqX1I6+9wDw6GGteVYDOjzU3+V1z4bvOgBf4/4jQsQiw u+OvzRWIc405DGW+x0Lt0NIGZdDcfVU= X-Google-Smtp-Source: ADFU+vuIz7VumbOT7QwCvwvQ4yOeAemUqNbYSrB+YLjOe3EcGBVGgZ+dUguoTpuBWv0zDQXhndsDfQ== X-Received: by 2002:a0c:e450:: with SMTP id d16mr13706287qvm.195.1584121173807; Fri, 13 Mar 2020 10:39:33 -0700 (PDT) Received: from ?IPv6:2001:4870:400e:409:8535:1893:92af:1c4e? ([2001:4870:400e:409:8535:1893:92af:1c4e]) by smtp.gmail.com with ESMTPSA id x74sm11200241qkb.40.2020.03.13.10.39.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 10:39:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Sean Turner In-Reply-To: <35C34180-8890-4A7B-85C5-419D4D9586C8@vigilsec.com> Date: Fri, 13 Mar 2020 13:39:31 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <7620E876-DCA6-47B2-8EBE-15F4698971F8@sn3rd.com> References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> <35C34180-8890-4A7B-85C5-419D4D9586C8@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Fri, 13 Mar 2020 17:39:37 -0000 Russ, This draft is pretty straightforward. Just some nits: 0) abstract/s1: Because this draft just addressed signed-data and = authenticated-data right up front? 1) s1 and s4.1: s/Singed-data/signed-data 2) s.4.1: s/Authenticated-data/authenticated-data 3) s6: s/Likewise there us not/Likewise there is not spt > On Mar 9, 2020, at 12:02 PM, Russ Housley = wrote: >=20 > I updated the section ong timestamps based on some comments from an = implementer. >=20 > Russ >=20 >=20 >> On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >>=20 >> Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection >> Author : Russ Housley >> Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt >> Pages : 8 >> Date : 2020-03-09 >>=20 >> Abstract: >> This document updates the Cryptographic Message Syntax (CMS) >> specified in RFC 5652 to ensure that algorithm identifiers are >> adequately protected. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 >> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Mar 13 11: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 BF7F13A0854 for ; Fri, 13 Mar 2020 11:24:52 -0700 (PDT) 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 FB_v8R4XWNxS for ; Fri, 13 Mar 2020 11:24:46 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D723A0853 for ; Fri, 13 Mar 2020 11:24:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2A79A300B0C for ; Fri, 13 Mar 2020 14:24:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nNGmT19FH7f1 for ; Fri, 13 Mar 2020 14:24:42 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 60768300464; Fri, 13 Mar 2020 14:24:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <7620E876-DCA6-47B2-8EBE-15F4698971F8@sn3rd.com> Date: Fri, 13 Mar 2020 14:24:43 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> <35C34180-8890-4A7B-85C5-419D4D9586C8@vigilsec.com> <7620E876-DCA6-47B2-8EBE-15F4698971F8@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Fri, 13 Mar 2020 18:24:53 -0000 Fixed in my edit buffer, except I could not find "Singed-data" in the = document. Russ > On Mar 13, 2020, at 1:39 PM, Sean Turner wrote: >=20 > Russ, >=20 > This draft is pretty straightforward. Just some nits: >=20 > 0) abstract/s1: Because this draft just addressed signed-data and = authenticated-data right up front? >=20 > 1) s1 and s4.1: s/Singed-data/signed-data >=20 > 2) s.4.1: s/Authenticated-data/authenticated-data >=20 > 3) s6: s/Likewise there us not/Likewise there is not >=20 > spt >=20 >> On Mar 9, 2020, at 12:02 PM, Russ Housley = wrote: >>=20 >> I updated the section ong timestamps based on some comments from an = implementer. >>=20 >> Russ >>=20 >>=20 >>> On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >>>=20 >>> Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection >>> Author : Russ Housley >>> Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt >>> Pages : 8 >>> Date : 2020-03-09 >>>=20 >>> Abstract: >>> This document updates the Cryptographic Message Syntax (CMS) >>> specified in RFC 5652 to ensure that algorithm identifiers are >>> adequately protected. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >>>=20 >>> There are also htmlized versions available at: >>> = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >=20 From nobody Fri Mar 13 13:20: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 905603A0E04 for ; Fri, 13 Mar 2020 13:20:17 -0700 (PDT) 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 1QyPykOjfVWv for ; Fri, 13 Mar 2020 13:20:16 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB4B3A0E03 for ; Fri, 13 Mar 2020 13:20:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D33D0300B17 for ; Fri, 13 Mar 2020 16:20:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OLxyeaPVsEtq for ; Fri, 13 Mar 2020 16:20:12 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 9C7543004C0 for ; Fri, 13 Mar 2020 16:20:12 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_2058B447-B9A1-4333-8B84-5EC1CD655BE0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <9AD47C99-D266-436C-84A6-065549810A20@vigilsec.com> Date: Fri, 13 Mar 2020 16:20:13 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Doodle: LAMPS WG Virtual Meeting on March 30th 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 Mar 2020 20:20:18 -0000 --Apple-Mail=_2058B447-B9A1-4333-8B84-5EC1CD655BE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear STIR WG: The IESG ha suggested that the STIR WG hold a virtual meeting on March = 30th. This doodle is to see if that date will work. If not, we will = pick another date. Please respond to the doodle poll by end of the day = on March 17th. https://doodle.com/poll/yg2wp5piyn8b7twx = Russ and Tim =3D =3D =3D =3D =3D =3D =3D =3D LAMPS WG Virtual Meeting Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-5480-ku-clarifications (Sean) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) b) draft-ietf-lamps-cms-update-alg-id-protect (Russ) c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) d) draft-ietf-lamps-cmp-updates (Henk) e) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) 4) Wrap Up= --Apple-Mail=_2058B447-B9A1-4333-8B84-5EC1CD655BE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = STIR WG:

The IESG ha suggested that the = STIR WG hold a virtual meeting on March 30th.  This doodle is to = see if that date will work.  If not, we will pick another date. =  Please respond to the doodle poll by end of the day on March = 17th.

https://doodle.com/poll/yg2wp5piyn8b7twx
Russ and Tim


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


LAMPS WG Virtual Meeting Agenda

0)=  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

2) =  Documents with the RFC Editor and IESG
  a) =  draft-ietf-lamps-5480-ku-clarifications (Sean)

3)  Active Working Group Documents
  a) =  draft-ietf-lamps-header-protection-requirements (Alexey, = Bernie)
  b) =  draft-ietf-lamps-cms-update-alg-id-protect (Russ)
  c)  draft-ietf-lamps-rfc7030est-clarify = (Michael, Thomas, Wei)
  d) =  draft-ietf-lamps-cmp-updates (Henk)
  e) =  draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David)

4)  Wrap Up
= --Apple-Mail=_2058B447-B9A1-4333-8B84-5EC1CD655BE0-- From nobody Fri Mar 13 13:34: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 E63483A0EBC for ; Fri, 13 Mar 2020 13:33:54 -0700 (PDT) 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 ioz3JZnJAH44 for ; Fri, 13 Mar 2020 13:33:53 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018023A0EBD for ; Fri, 13 Mar 2020 13:33:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 99F7B300A93 for ; Fri, 13 Mar 2020 16:33:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zk2LA6XLyzqi for ; Fri, 13 Mar 2020 16:33:49 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 483563004C0 for ; Fri, 13 Mar 2020 16:33:49 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD560D2-82F0-434C-B124-5B4D9C05A391" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 13 Mar 2020 16:33:50 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Doodle: LAMPS WG Virtual Meeting on March 30th 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 Mar 2020 20:34:07 -0000 --Apple-Mail=_AAD560D2-82F0-434C-B124-5B4D9C05A391 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear LAMPS WG: Correcting the typo in the earlier message .... The IESG ha suggested that the LAMPS WG hold a virtual meeting on March = 30th. This doodle is to see if that date will work. If not, we will = pick another date. Please respond to the doodle poll by end of the day = on March 17th. https://doodle.com/poll/yg2wp5piyn8b7twx = Russ and Tim =3D =3D =3D =3D =3D =3D =3D =3D LAMPS WG Virtual Meeting Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-5480-ku-clarifications (Sean) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) b) draft-ietf-lamps-cms-update-alg-id-protect (Russ) c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) d) draft-ietf-lamps-cmp-updates (Henk) e) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) 4) Wrap Up --Apple-Mail=_AAD560D2-82F0-434C-B124-5B4D9C05A391 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = LAMPS WG:

Correcting the typo in the earlier message ....

The IESG ha suggested that the LAMPS WG hold a = virtual meeting on March 30th.  This doodle is to see if that date = will work.  If not, we will pick another date.  Please respond = to the doodle poll by end of the day on March 17th.

https://doodle.com/poll/yg2wp5piyn8b7twx
Russ and Tim


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


LAMPS WG Virtual Meeting Agenda

0)=  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

2) =  Documents with the RFC Editor and IESG
  a) =  draft-ietf-lamps-5480-ku-clarifications (Sean)

3)  Active Working Group Documents
  a) =  draft-ietf-lamps-header-protection-requirements (Alexey, = Bernie)
  b) =  draft-ietf-lamps-cms-update-alg-id-protect (Russ)
  c)  draft-ietf-lamps-rfc7030est-clarify = (Michael, Thomas, Wei)
  d) =  draft-ietf-lamps-cmp-updates (Henk)
  e) =  draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David)

4)  Wrap Up

= --Apple-Mail=_AAD560D2-82F0-434C-B124-5B4D9C05A391-- From nobody Wed Mar 18 15:35: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 EAF773A1D8B for ; Wed, 18 Mar 2020 15:35:46 -0700 (PDT) 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 mZnpX3gL-4pc for ; Wed, 18 Mar 2020 15:35:43 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 733193A1D8C for ; Wed, 18 Mar 2020 15:35:43 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id n21so217188ioo.10 for ; Wed, 18 Mar 2020 15:35:43 -0700 (PDT) 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=ua+PNfWj+rorW/5ilXeZwYw485Dav/pa0mKGP9rBXtw=; b=XPy51fkEw+M/kpFhyGCUOMJ4CmZL2Z6iNj2+IxkB+RPd1d7W+vjl9twaY4jTvmuM/w 0UQunranvCe3NQ7O6mE5VUFpEjP/sQH8kwAEYyL+d9L1L68tXlMP6Hxbqv8CaOHQy+CN zPBxRusbk7Teosos62Ht+jvVIMPaj7d/FLsDR86L7+dPtsM2sGzdVvTDxxDsSFlNvpSb /dk2F+AKnVEQaR1pq5glpBArTicPDb7pzMZ4TnXD09Bv/6qS7Me28q/ATjieUrOZz4tN f1c5Y1Iue957pvpZoTo7r+yWSjq/7NBKHx9dd+I6OMVBIFPcyKNsNN1IJ3jbSycc5DGo mQ8Q== 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=ua+PNfWj+rorW/5ilXeZwYw485Dav/pa0mKGP9rBXtw=; b=cw2aOWiBh8cY14X756QXqPrYUZHYxpowcbAH4G0G2sSrUavH/waUEsxpLnK2ekxhzj pdrWR3NJIbz5GLNEm6gvIpLdz6XO/m82IVUrfDtqxdhF54dfPDz10BxhUYwRJlsx8UnT rW3e1sbCocoDN3UPxhnkBSQ7gfCG1TzV/5ixY3EXMzwzEGcwkm7kOu99k6LZVqchJ2Mn FmZrZoE5V1Vvdsvyyn8AoUkf93IHxjBIjqNT3J06THgEKVOyPl28ovsWnp5MmgVC/zRY wM6DQOVRGFnM4x+qp2lbrDoVAelEH71wXumIR3EEinYrB2OvC6EEdGjfmkaCLT5MUOTT wRYw== X-Gm-Message-State: ANhLgQ1XW9UEYkspwb3WEBrO3nXEEtT7mW1x/P6C18MsnjKxpeDI+rA+ ZzvuOUr+GGEGULXzF1FWdsZKxZaylTJf+yfsblS66g== X-Google-Smtp-Source: ADFU+vsC6BtJQeYnbW1EiMcXrJvGD2F9LLvOX/+FwEOQEoYMmF9dMi1giWTD+QIfSGBHdBEsds5B4Ts+S8VUArUI2zs= X-Received: by 2002:a02:9608:: with SMTP id c8mr338142jai.68.1584570942566; Wed, 18 Mar 2020 15:35:42 -0700 (PDT) MIME-Version: 1.0 References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> In-Reply-To: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> From: Mohit Sahni Date: Wed, 18 Mar 2020 15:35:31 -0700 Message-ID: To: Russ Housley Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="0000000000002734cf05a128ac51" Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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: Wed, 18 Mar 2020 22:35:47 -0000 --0000000000002734cf05a128ac51 Content-Type: text/plain; charset="UTF-8" Hi Russ, I have updated the draft with the changes that you have suggested. Please let me know if they are ok to move forward. Thanks Mohit On Thu, Mar 12, 2020 at 11:40 AM Russ Housley wrote: > > Mohit: > > I have two concerns with the document. > > First, the Abstract and Introduction talk about "the updated format". > This is not really what is happening. The nonce in RFC 6960 is an OCTET > STRING, and the nonce with this update is still an OCTET STRING. I think > it would be better to describe this a clarification on the sizes of nonces > that should be supported by an OCSP implementation. > > Second, updates to an RFC usually have OLD and NEW text. In this case the > NEW text needs to be provided for three sections. > > -- Section 4.4.1: The NEW text is essentially Section 2.1 of your > Internet-Draft. > > -- Appendix B.1: I do not see a specification in this module for Nonce. > It should be there. So, your document should add a line: > > Nonce ::= OCTET STRING(SIZE(1..32)) > > -- Appendix B.2: The re-ocsp-nonce EXTENSION definition should be updated: > > OLD: > > re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED > BY id-pkix-ocsp-nonce } > > NEW: > > Nonce ::= OCTET STRING(SIZE(1..32)) > > re-ocsp-nonce EXTENSION ::= { SYNTAX Nonce IDENTIFIED > BY id-pkix-ocsp-nonce } > > > Russ > > > On Mar 12, 2020, at 12:53 PM, Mohit Sahni wrote: > > Hi All, > I recently proposed a draft for properly defining the OCSP nonce > extension, specifically the length of the extension. Based on feedback I > got from the LAPMS WG members, I have updated the draft > (draft-msahni-lamps-ocsp-nonce-01) at > https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ > . > > I will request the WG members to kindly adopt the draft as an active > working group document and get it published. > > Thanks > Mohit > > > --0000000000002734cf05a128ac51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Russ,
I have=C2=A0updated the draft with the c= hanges that you have suggested. Please let me know if they are ok to move f= orward.=C2=A0

Thanks
Mohit=C2=A0

On= Thu, Mar 12, 2020 at 11:40 AM Russ Housley <housley@vigilsec.com> wrote:
=
Mohit:

I have two concerns with the docum= ent.

First, the Abstract and Introduction talk abo= ut "the updated format".=C2=A0 This is not really what is happeni= ng.=C2=A0 The nonce in RFC 6960 is an OCTET STRING, and the nonce with this= update is still an OCTET STRING.=C2=A0 I think it would be better to descr= ibe this a clarification on the sizes of nonces that should be supported by= an OCSP implementation.

Second, updates to an RFC= usually have OLD and NEW text.=C2=A0 In this case the NEW text needs to be= provided for three sections.

-- Section 4.4.1: = =C2=A0The NEW text is essentially Section 2.1 of your Internet-Draft.
=

-- Appendix B.1: =C2=A0I do not see a specification in = this module for Nonce.=C2=A0 It should be there.=C2=A0 So, your document sh= ould add a line:

=C2=A0 =C2=A0 =C2=A0 Nonce ::=3D = OCTET STRING(SIZE(1..32))

-- Appendix B.2: The re-= ocsp-nonce EXTENSION definition should be updated:

OLD:

re-ocsp-nonce EXTENSION ::=3D { SYNTAX = OCTET STRING IDENTIFIED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BY id-pkix-= ocsp-nonce }

NEW:

No= nce ::=3D OCTET STRING(SIZE(1..32))

re-= ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce IDENTIFIED
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 BY id-pkix-ocsp-nonce }


Russ


On Mar 12, 2020, at 12:53 PM, Mohit Sahni <mohit06jan@gmail.com> wrote= :

Hi All,
I recently proposed a draf= t for properly defining the OCSP nonce extension, specifically the length o= f the extension.=C2=A0Based on feedback I got from the LAPMS=C2=A0WG member= s, I have updated the draft (draft-msahni-lamps-ocsp-nonce-01) at=C2=A0https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-no= nce/=C2=A0.=C2=A0

I will request the WG member= s to kindly adopt=C2=A0the draft as an active working group document and ge= t it published.

Thanks
Mohit=C2=A0
=

--0000000000002734cf05a128ac51-- From nobody Thu Mar 19 08:58: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 74F8F3A0814 for ; Thu, 19 Mar 2020 08:58:36 -0700 (PDT) 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 d8EfoB1eeYIC for ; Thu, 19 Mar 2020 08:58:32 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B5D93A0812 for ; Thu, 19 Mar 2020 08:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0398F300B4C for ; Thu, 19 Mar 2020 11:58:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GGqVpFRX0kAw for ; Thu, 19 Mar 2020 11:58:27 -0400 (EDT) Received: from [192.168.50.205] (wsip-70-191-149-90.dc.dc.cox.net [70.191.149.90]) by mail.smeinc.net (Postfix) with ESMTPSA id 0A8FD300A20; Thu, 19 Mar 2020 11:58:26 -0400 (EDT) From: Russ Housley Message-Id: <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1494CB90-2FB6-41FA-B62A-188E0ADFA816" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 11:58:28 -0400 In-Reply-To: Cc: spasm@ietf.org To: Mohit Sahni References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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 Mar 2020 15:58:38 -0000 --Apple-Mail=_1494CB90-2FB6-41FA-B62A-188E0ADFA816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mohit: Section 5.1 does not look correct to me. The OIDs are at the bottom of = the ASN.1 module. Only Nonce is not defined. I would like to hear what other people think about adopting this = document. If we are going to adopt it, then this small thing can be = fixed in the first WG version. Russ > On Mar 18, 2020, at 6:35 PM, Mohit Sahni wrote: >=20 > Hi Russ, > I have updated the draft with the changes that you have suggested. = Please let me know if they are ok to move forward.=20 >=20 > Thanks > Mohit=20 >=20 > On Thu, Mar 12, 2020 at 11:40 AM Russ Housley > wrote: >=20 > Mohit: >=20 > I have two concerns with the document. >=20 > First, the Abstract and Introduction talk about "the updated format". = This is not really what is happening. The nonce in RFC 6960 is an OCTET = STRING, and the nonce with this update is still an OCTET STRING. I = think it would be better to describe this a clarification on the sizes = of nonces that should be supported by an OCSP implementation. >=20 > Second, updates to an RFC usually have OLD and NEW text. In this case = the NEW text needs to be provided for three sections. >=20 > -- Section 4.4.1: The NEW text is essentially Section 2.1 of your = Internet-Draft. >=20 > -- Appendix B.1: I do not see a specification in this module for = Nonce. It should be there. So, your document should add a line: >=20 > Nonce ::=3D OCTET STRING(SIZE(1..32)) >=20 > -- Appendix B.2: The re-ocsp-nonce EXTENSION definition should be = updated: >=20 > OLD: >=20 > re-ocsp-nonce EXTENSION ::=3D { SYNTAX OCTET STRING IDENTIFIED > BY id-pkix-ocsp-nonce } >=20 > NEW: >=20 > Nonce ::=3D OCTET STRING(SIZE(1..32)) >=20 > re-ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce IDENTIFIED > BY id-pkix-ocsp-nonce } >=20 >=20 > Russ >=20 >=20 >> On Mar 12, 2020, at 12:53 PM, Mohit Sahni > wrote: >>=20 >> Hi All, >> I recently proposed a draft for properly defining the OCSP nonce = extension, specifically the length of the extension. Based on feedback I = got from the LAPMS WG members, I have updated the draft = (draft-msahni-lamps-ocsp-nonce-01) at = https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ = .=20 >>=20 >> I will request the WG members to kindly adopt the draft as an active = working group document and get it published. >>=20 >> Thanks >> Mohit=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_1494CB90-2FB6-41FA-B62A-188E0ADFA816 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Mohit:

Section 5.1 does not look correct to me.  The OIDs are = at the bottom of the ASN.1 module.  Only Nonce is not = defined.

I = would like to hear what other people think about adopting this document. =  If we are going to adopt it, then this small thing can be fixed in = the first WG version.

Russ

On Mar 18, 2020, at 6:35 PM, = Mohit Sahni <mohit06jan@gmail.com> wrote:

Hi Russ,
I have updated the draft = with the changes that you have suggested. Please let me know if they are = ok to move forward. 

Thanks
Mohit 

On Thu, Mar 12, 2020 at 11:40 AM Russ Housley = <housley@vigilsec.com> wrote:

Mohit:

I have two concerns with = the document.

First, the Abstract and Introduction talk about "the updated = format".  This is not really what is happening.  The nonce in = RFC 6960 is an OCTET STRING, and the nonce with this update is still an = OCTET STRING.  I think it would be better to describe this a = clarification on the sizes of nonces that should be supported by an OCSP = implementation.

Second, updates to an RFC usually have OLD and NEW = text.  In this case the NEW text needs to be provided for three = sections.

-- = Section 4.4.1:  The NEW text is essentially Section 2.1 of your = Internet-Draft.

-- Appendix B.1:  I do not see a specification in this = module for Nonce.  It should be there.  So, your document = should add a line:

      Nonce ::=3D OCTET = STRING(SIZE(1..32))

-- Appendix B.2: The re-ocsp-nonce EXTENSION definition = should be updated:

OLD:

re-ocsp-nonce EXTENSION ::=3D { SYNTAX OCTET = STRING IDENTIFIED
        =                     =   BY id-pkix-ocsp-nonce }

NEW:

Nonce ::=3D OCTET = STRING(SIZE(1..32))

re-ocsp-nonce EXTENSION ::=3D { SYNTAX Nonce = IDENTIFIED
          =                     BY = id-pkix-ocsp-nonce }


Russ


On Mar 12, 2020, at 12:53 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:

Hi All,
I recently proposed a draft for properly defining the OCSP = nonce extension, specifically the length of the extension. Based on = feedback I got from the LAPMS WG members, I have updated the draft = (draft-msahni-lamps-ocsp-nonce-01) at https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce= / . 

I will request the WG members to kindly adopt the draft = as an active working group document and get it published.

Thanks
Mohit 

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

= --Apple-Mail=_1494CB90-2FB6-41FA-B62A-188E0ADFA816-- From nobody Thu Mar 19 09:04: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 DDA3B3A083F for ; Thu, 19 Mar 2020 09:04:20 -0700 (PDT) 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, 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_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 (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 HJSIf2lV1Gd4 for ; Thu, 19 Mar 2020 09:04:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A233A0839 for ; Thu, 19 Mar 2020 09:04:19 -0700 (PDT) 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 02JFhKP4029827; Thu, 19 Mar 2020 16:04: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=TX4CMbRDPmNiRArycksf8HFBbktK7PCkUy2Hg3eAUZc=; b=LSSQ4S4zS03kcPDMwNYfMvAsbw3e6ydwZ7dPj8hA+KTjgQDoljcIJvbvdXMsrcz29uGU 1RpP07JYgGU1lDyHeoOFPgHXngoBR8m2ONWcuHiPgV2VAqVwg1rjhoc9kl0FX6hqQov2 3ep+63r40GpQuNZ/ktBB7cnlrTS4YgOVyL4Egjtz71nx9dmFZ0AXadLbyTkThvLDSqf8 lxKZnsjTjrwVRFk3mljX1SBQN0lb1gfVbpxZX41cjMNg+fM6beQE49fhSSD3rjwKrngJ MTajbhPEQ2j3t4re8HPwkDjgocv1AQaIvynwOjku2EZhae/+roLJDkW3ZNW0pGK0tQGG wQ== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2yrr6px4s8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 16:04:18 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02JG2nXp021178; Thu, 19 Mar 2020 12:04:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 2yrtkvcjn3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 12:04:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 19 Mar 2020 12:04:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Thu, 19 Mar 2020 12:04:16 -0400 From: "Salz, Rich" To: Russ Housley , Mohit Sahni CC: "spasm@ietf.org" Thread-Topic: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP Nonce extension) Thread-Index: AQHV+I7e+J+5Rfkw/E6VOpJgaPh+5qhFjXEAgAmvj4CAASNlAP//vo8A Date: Thu, 19 Mar 2020 16:04:15 +0000 Message-ID: <10DD95F6-3829-4AFC-B463-E8289AE3936F@akamai.com> References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> In-Reply-To: <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: multipart/alternative; boundary="_000_10DD95F638294AFCB463E8289AE3936Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-19_06:2020-03-19, 2020-03-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=908 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003190069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.645 definitions=2020-03-19_05:2020-03-19, 2020-03-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 spamscore=0 priorityscore=1501 adultscore=0 suspectscore=0 mlxlogscore=886 clxscore=1015 bulkscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003190069 Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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 Mar 2020 16:04:21 -0000 --_000_10DD95F638294AFCB463E8289AE3936Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIERFUiBlbmNvZGluZyBkb2VzbuKAmXQgY2hhbmdlLCByaWdodD8NCg0KU3VyZSwgdGhpcyBz ZWVtcyBsaWtlIGEgc21hbGwgc2ltcGxlIHRoaW5nIHRvIGRvLCByaWdodCBpbiBvdXIgY2hhcnRl ci4NCg0KT25lIHNlbnRlbmNlIOKAnHRoaXMgYXNzaWducyBhIG1heGltdW0gc2l6ZSB0byB0aGUg Tm9uY2UgZXh0ZW5zaW9u4oCdIHdvdWxkIGJlIG5pY2UuDQo= --_000_10DD95F638294AFCB463E8289AE3936Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <388835DDCC1FF849ABEA2959C65D7A59@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgREVSIGVuY29kaW5nIGRvZXNu4oCZ dCBjaGFuZ2UsIHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlLCB0aGlzIHNlZW1z IGxpa2UgYSBzbWFsbCBzaW1wbGUgdGhpbmcgdG8gZG8sIHJpZ2h0IGluIG91ciBjaGFydGVyLg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgc2VudGVuY2Ug4oCcdGhpcyBhc3Np Z25zIGEgbWF4aW11bSBzaXplIHRvIHRoZSBOb25jZSBleHRlbnNpb27igJ0gd291bGQgYmUgbmlj ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_10DD95F638294AFCB463E8289AE3936Fakamaicom_-- From nobody Thu Mar 19 09:09: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 5BC893A085E for ; Thu, 19 Mar 2020 09:09:53 -0700 (PDT) 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 h_ZryHKGiY-Y for ; Thu, 19 Mar 2020 09:09:51 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 437393A0851 for ; Thu, 19 Mar 2020 09:09:51 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id p2so2728624ile.9 for ; Thu, 19 Mar 2020 09:09:51 -0700 (PDT) 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=xGq2AXKO3OoxoRX7IiG3JlHuvU+MdyXEqe+/f+RJsGc=; b=gOGwbCgMyi7nWzGTjT1H07gFxEKikASGxmVfBuU+4JxuIBICXxC3Y+J9DI3Dayz3Pp 3Y1PvObBudk0wqyQDTp34+gxTlgDpmNxXdvpzx+wk2kD4OuhmDg4NTMB1oNK6htTVLgj Mx7KnLgwpVb9Q5V8YM4h4TEAS2io18orcKPl12EB5gF0V1XPIa1Ocf/91FnYzEYp1Mp0 aokUFYVmJmJAm+YIhmG7xzRh5MKiYtD966OjWRE/+OWQZaHV+7Vhxhca+B4m/g70lQoP 1R63YGrHBK8aWp0DV8aXshnh4Eh8j+rHLbptFtM/X2FheMKJtSM6r5Thx4N/XRj1h/Fl ZjYw== 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=xGq2AXKO3OoxoRX7IiG3JlHuvU+MdyXEqe+/f+RJsGc=; b=IHR/QCKtdPBTBCEtYijS7YOqmKakjfbDZQgzSm0SgHHndMwcUT4l3lETx82l0Kys6G l8Jyhos3L0n0N3/7VnS0OyIpGNCLdJAN1Tk3FCcpCTIH5Fn5fuiW0duckx/iWbGVxulp pehzc+tXxhULxZkN0yOTGRIvvoyFLn+AFdENk5Bc8f+HKCeercJuxyoQLEYfaW4Jn5dH UuwFGiFPUAaBMnG5pTCj+w0ZOTHAHPYxfb9Ro6qK0XrKY7gQ8HLvFBiBmJAIVkI78rd3 8FnrNRDa1xknj1aZwohhgiis8nWAORVumInEDvzZ6yHmrhL97X3oDypo70daGTBpBuax wk9g== X-Gm-Message-State: ANhLgQ3IQHGKQeMMC28cEKNqyZfcLM33zMMrFQBZm5iRN74qNjTlGGk4 shAa/z3iJyKmHE6GkrUdmBby7dEg6RvXgc6ueMg= X-Google-Smtp-Source: ADFU+vvYx+UG+PM1JrAvkLxJIVnI9XChqlZ6FZFESpa5lnLvtVF3jW/weYrITQn9IALUU3uZvqGwzZ70IBfGoTK2GBw= X-Received: by 2002:a92:5c4c:: with SMTP id q73mr4068734ilb.46.1584634189548; Thu, 19 Mar 2020 09:09:49 -0700 (PDT) MIME-Version: 1.0 References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> In-Reply-To: <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> From: Mohit Sahni Date: Thu, 19 Mar 2020 09:09:37 -0700 Message-ID: To: Russ Housley Cc: spasm@ietf.org Content-Type: multipart/alternative; boundary="000000000000f7977305a13765cf" Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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 Mar 2020 16:09:53 -0000 --000000000000f7977305a13765cf Content-Type: text/plain; charset="UTF-8" Hi Russ, I added the OID's to give some context along with the definition of Nonce. The reason being that the RFC 6960 only defines the OIDs of the extensions and does not define any of the extensions, they assumed extensions are defined in their respective sections in the RFC. If it's causing more confusion, I will remove the OID information. Thanks Mohit On Thu, Mar 19, 2020 at 8:58 AM Russ Housley wrote: > Mohit: > > Section 5.1 does not look correct to me. The OIDs are at the bottom of > the ASN.1 module. Only Nonce is not defined. > > I would like to hear what other people think about adopting this > document. If we are going to adopt it, then this small thing can be fixed > in the first WG version. > > Russ > > On Mar 18, 2020, at 6:35 PM, Mohit Sahni wrote: > > Hi Russ, > I have updated the draft with the changes that you have suggested. Please > let me know if they are ok to move forward. > > Thanks > Mohit > > On Thu, Mar 12, 2020 at 11:40 AM Russ Housley > wrote: > >> >> Mohit: >> >> I have two concerns with the document. >> >> First, the Abstract and Introduction talk about "the updated format". >> This is not really what is happening. The nonce in RFC 6960 is an OCTET >> STRING, and the nonce with this update is still an OCTET STRING. I think >> it would be better to describe this a clarification on the sizes of nonces >> that should be supported by an OCSP implementation. >> >> Second, updates to an RFC usually have OLD and NEW text. In this case >> the NEW text needs to be provided for three sections. >> >> -- Section 4.4.1: The NEW text is essentially Section 2.1 of your >> Internet-Draft. >> >> -- Appendix B.1: I do not see a specification in this module for Nonce. >> It should be there. So, your document should add a line: >> >> Nonce ::= OCTET STRING(SIZE(1..32)) >> >> -- Appendix B.2: The re-ocsp-nonce EXTENSION definition should be updated: >> >> OLD: >> >> re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED >> BY id-pkix-ocsp-nonce } >> >> NEW: >> >> Nonce ::= OCTET STRING(SIZE(1..32)) >> >> re-ocsp-nonce EXTENSION ::= { SYNTAX Nonce IDENTIFIED >> BY id-pkix-ocsp-nonce } >> >> >> Russ >> >> >> On Mar 12, 2020, at 12:53 PM, Mohit Sahni wrote: >> >> Hi All, >> I recently proposed a draft for properly defining the OCSP nonce >> extension, specifically the length of the extension. Based on feedback I >> got from the LAPMS WG members, I have updated the draft >> (draft-msahni-lamps-ocsp-nonce-01) at >> https://datatracker..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/ >> . >> >> I will request the WG members to kindly adopt the draft as an active >> working group document and get it published. >> >> Thanks >> Mohit >> >> >> _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > --000000000000f7977305a13765cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Russ,
I added the OID's to give some conte= xt along with the definition of Nonce. The reason being that=C2=A0the RFC 6= 960 only defines the OIDs of the extensions and does not define any of the = extensions, they assumed extensions are defined in their respective section= s in the RFC. If it's=C2=A0causing more confusion, I will remove the OI= D information.=C2=A0

Thanks
Mohit=C2=A0<= /div>

On Thu, Mar 19, 2020 at 8:58 AM Russ Housley <housley@vigilsec.com> wrote:
Mohit:

Section 5.1 does not look correct to me.=C2= =A0 The OIDs are at the bottom of the ASN.1 module.=C2=A0 Only Nonce is not= defined.

I would like to hear what other people t= hink about adopting this document.=C2=A0 If we are going to adopt it, then = this small thing can be fixed in the first WG version.

=
Russ

On Mar 18, 2020, at 6:= 35 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:

Hi= =C2=A0Russ,
I have=C2=A0updated the draft with the changes that you hav= e suggested. Please let me know if they are ok to move forward.=C2=A0
=

Thanks
Mohit=C2=A0

On Thu, Mar 12, 2020= at 11:40 AM Russ Housley <housley@vigilsec.com> wrote:

Mohit:

<= div>I have two concerns with the document.

First, = the Abstract and Introduction talk about "the updated format".=C2= =A0 This is not really what is happening.=C2=A0 The nonce in RFC 6960 is an= OCTET STRING, and the nonce with this update is still an OCTET STRING.=C2= =A0 I think it would be better to describe this a clarification on the size= s of nonces that should be supported by an OCSP implementation.
<= br>
Second, updates to an RFC usually have OLD and NEW text.=C2= =A0 In this case the NEW text needs to be provided for three sections.

-- Section 4.4.1: =C2=A0The NEW text is essentially Se= ction 2.1 of your Internet-Draft.

-- Appendix B.1:= =C2=A0I do not see a specification in this module for Nonce.=C2=A0 It shou= ld be there.=C2=A0 So, your document should add a line:

=C2=A0 =C2=A0 =C2=A0 Nonce ::=3D OCTET STRING(SIZE(1..32))
=
-- Appendix B.2: The re-ocsp-nonce EXTENSION definition shou= ld be updated:

OLD:

= re-ocsp-nonce EXTENSION ::=3D { SYNTAX OCTET STRING IDENTIFIED
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BY id-pkix-ocsp-nonce }

NEW:

Nonce ::=3D OCTET STRING(SIZE(1..3= 2))

re-ocsp-nonce EXTENSION ::=3D { SYN= TAX Nonce IDENTIFIED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BY id-pkix-o= csp-nonce }


Russ
<= div>

On Mar 12, 2020, at 1= 2:53 PM, Mohit Sahni <mohit06jan@gmail.com> wrote:

= Hi All,
I recently proposed a draft for properly defining the OCSP = nonce extension, specifically the length of the extension.=C2=A0Based on fe= edback I got from the LAPMS=C2=A0WG members, I have updated the draft (draf= t-msahni-lamps-ocsp-nonce-01) at=C2=A0https://datatracke= r..ietf.org/doc/draft-msahni-lamps-ocsp-nonce/=C2=A0.=C2=A0
<= br>
I will request the WG members to kindly adopt=C2=A0the draft = as an active working group document and get it published.

Thanks
Mohit=C2=A0
_______________________________________________
Spasm mailing list
Spasm@ietf.org
http= s://www.ietf.org/mailman/listinfo/spasm
--000000000000f7977305a13765cf-- From nobody Thu Mar 19 10:15: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 1F6683A09EE for ; Thu, 19 Mar 2020 10:15:15 -0700 (PDT) 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 WPFMSVxStgza for ; Thu, 19 Mar 2020 10:15:13 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB1B3A09E5 for ; Thu, 19 Mar 2020 10:15:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3CF06300B34 for ; Thu, 19 Mar 2020 13:15:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4FE2NcOdNjsL for ; Thu, 19 Mar 2020 13:15:09 -0400 (EDT) Received: from [192.168.50.205] (wsip-70-191-149-90.dc.dc.cox.net [70.191.149.90]) by mail.smeinc.net (Postfix) with ESMTPSA id 623F2300A20; Thu, 19 Mar 2020 13:15:09 -0400 (EDT) From: Russ Housley Message-Id: <9600E759-3C31-428A-B79B-F5E37D183D7F@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FCADA952-E06E-4E25-88C0-56F8A07D7494" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 13:15:10 -0400 In-Reply-To: <10DD95F6-3829-4AFC-B463-E8289AE3936F@akamai.com> Cc: Mohit Sahni , "spasm@ietf.org" To: Rich Salz References: <4ED41D6F-1E97-4DCC-ABEB-9E81B18EEB18@vigilsec.com> <50146CE7-F096-4931-8B2A-7A180FDB80AB@vigilsec.com> <10DD95F6-3829-4AFC-B463-E8289AE3936F@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Request for adopting draft-msahni-lamps-ocsp-nonce by the LAMPS WG (RFC6960: Issue with the OCSP 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 Mar 2020 17:15:15 -0000 --Apple-Mail=_FCADA952-E06E-4E25-88C0-56F8A07D7494 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 19, 2020, at 12:04 PM, Salz, Rich wrote: >=20 > The DER encoding doesn=E2=80=99t change, right? Correct! =20 > Sure, this seems like a small simple thing to do, right in our = charter. > =20 > One sentence =E2=80=9Cthis assigns a maximum size to the Nonce = extension=E2=80=9D would be nice. +1 Russ --Apple-Mail=_FCADA952-E06E-4E25-88C0-56F8A07D7494 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 19, 2020, at 12:04 PM, Salz, Rich <rsalz@akamai.com> = wrote:

The DER = encoding doesn=E2=80=99t change, = right?

Correct!
 
Sure, = this seems like a small simple thing to do, right in our charter.
 
One sentence =E2=80=9Cthis assigns a maximum size to the = Nonce extension=E2=80=9D would be = nice.

+1

Russ
= --Apple-Mail=_FCADA952-E06E-4E25-88C0-56F8A07D7494-- From nobody Thu Mar 19 13:50: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 BB99E3A0F54 for ; Thu, 19 Mar 2020 13:50:22 -0700 (PDT) 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 qZqfDC5fDIv7 for ; Thu, 19 Mar 2020 13:50:18 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0313A0F51 for ; Thu, 19 Mar 2020 13:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A40ED300ABE for ; Thu, 19 Mar 2020 16:50:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5TEUkwTgLhaL for ; Thu, 19 Mar 2020 16:50:14 -0400 (EDT) Received: from [192.168.50.205] (wsip-70-191-149-90.dc.dc.cox.net [70.191.149.90]) by mail.smeinc.net (Postfix) with ESMTPSA id 5F40B3005DB for ; Thu, 19 Mar 2020 16:50:14 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_30940035-F4D1-4B96-BD12-47209DF70286" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Mar 2020 16:50:15 -0400 References: <9AD47C99-D266-436C-84A6-065549810A20@vigilsec.com> To: LAMPS WG In-Reply-To: <9AD47C99-D266-436C-84A6-065549810A20@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Doodle: LAMPS WG Virtual Meeting on March 30th 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 Mar 2020 20:50:23 -0000 --Apple-Mail=_30940035-F4D1-4B96-BD12-47209DF70286 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It looks like we can have a good number of people on March 30th at 10:30 = Eastern. I will submit the virtual meeting request for that time. Russ > On Mar 13, 2020, at 4:20 PM, Russ Housley = wrote: >=20 > Dear STIR WG: >=20 > The IESG ha suggested that the STIR WG hold a virtual meeting on March = 30th. This doodle is to see if that date will work. If not, we will = pick another date. Please respond to the doodle poll by end of the day = on March 17th. >=20 > https://doodle.com/poll/yg2wp5piyn8b7twx = >=20 > Russ and Tim >=20 >=20 > =3D =3D =3D =3D =3D =3D =3D =3D >=20 >=20 > LAMPS WG Virtual Meeting Agenda >=20 > 0) Minute Taker, Jabber Scribe, Bluesheets >=20 > 1) Agenda Bash >=20 > 2) Documents with the RFC Editor and IESG > a) draft-ietf-lamps-5480-ku-clarifications (Sean) >=20 > 3) Active Working Group Documents > a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) > b) draft-ietf-lamps-cms-update-alg-id-protect (Russ) > c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) > d) draft-ietf-lamps-cmp-updates (Henk) > e) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) >=20 > 4) Wrap Up > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_30940035-F4D1-4B96-BD12-47209DF70286 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It = looks like we can have a good number of people on March 30th at 10:30 = Eastern.  I will submit the virtual meeting request for that = time.

Russ


On Mar 13, 2020, at 4:20 PM, Russ Housley = <housley@vigilsec.com> wrote:

Dear = STIR WG:

The IESG ha suggested that the = STIR WG hold a virtual meeting on March 30th.  This doodle is to = see if that date will work.  If not, we will pick another date. =  Please respond to the doodle poll by end of the day on March = 17th.

https://doodle.com/poll/yg2wp5piyn8b7twx
Russ and Tim


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


LAMPS WG Virtual Meeting Agenda

0)=  Minute Taker, Jabber Scribe, Bluesheets

1)  Agenda Bash

2) =  Documents with the RFC Editor and IESG
  a) =  draft-ietf-lamps-5480-ku-clarifications (Sean)

3)  Active Working Group Documents
  a) =  draft-ietf-lamps-header-protection-requirements (Alexey, = Bernie)
  b) =  draft-ietf-lamps-cms-update-alg-id-protect (Russ)
  c)  draft-ietf-lamps-rfc7030est-clarify = (Michael, Thomas, Wei)
  d) =  draft-ietf-lamps-cmp-updates (Henk)
  e) =  draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David)

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

= --Apple-Mail=_30940035-F4D1-4B96-BD12-47209DF70286-- From nobody Thu Mar 19 13:57:00 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 65A683A0F74; Thu, 19 Mar 2020 13:56:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.121.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158465141829.15781.17955706678289682821@ietfa.amsl.com> Date: Thu, 19 Mar 2020 13:56:58 -0700 Archived-At: Subject: [lamps] lamps - New Interim Meeting Request 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: Thu, 19 Mar 2020 20:56:58 -0000 A new interim meeting request has just been submitted by Russ Housley. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-lamps-01 --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Meeting Type: Virtual Meeting Session 1: Date: 2020-03-30 Start Time: 10:30 America/New_York Duration: 01:30 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: --------------------------------------------------------- From nobody Mon Mar 23 16:07: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 14C813A0ED7 for ; Mon, 23 Mar 2020 16:07:39 -0700 (PDT) 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 kFf74wx0MF62 for ; Mon, 23 Mar 2020 16:07:37 -0700 (PDT) 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 6A6D73A0D3F for ; Mon, 23 Mar 2020 16:07:37 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id k13so5680456qki.2 for ; Mon, 23 Mar 2020 16:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pn+xcq9d9gfKfeWOLeGOA8KbckkfWMLMdpcsPqMNr4s=; b=caULnevWOR40LyMBiSzwTf3jlATANgNtX0NiAxjBK9pOt674gaRx/3WiStorKo2IBi 3CEctfzsc/rJb24fBMfRRETldOT4r4TyHhkQiR6nECY1174/RvTKYvTU69/61LHOQEsZ iSq5rKpvU1QVW91Z6X9OKRyD4vqvwcZ4vLAqI= 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=pn+xcq9d9gfKfeWOLeGOA8KbckkfWMLMdpcsPqMNr4s=; b=O7V34oZl4WJv5fKHzaVeraZ0Aeht0fQfWhxr+kSu3HLfSCdUXup+NbXEoQ6ssXXPSr ZqVRyoK8aOo2FxlEATp40Gzu17GY3xETXbFBC9GU3mk0rkoqX8Pz0IkRfoB37Zh8vcvL i53xCkpDlYoETehVAH9uDs4oxTlcpV0Gw9YXbj4plTetjozxiw9oWjIFz5kqwwntqUp/ cdMFNywkFk4mtDwcfYzlDTKCsr8zfAnojf6FNgVQ1v0GhVLpvTIKSjmpA0yeopoQixjw M2KkGCrCKbKi5ljwrFrQn3N8NBE7NoL5sx+e4/h84KNCBffebKYBAi7g3kq7FcLqLPHA XEHQ== X-Gm-Message-State: ANhLgQ35KONMsbuX5a0nTZLrs/1R2GOQQveWSNi8EHQonTA8MUbgr8J0 owfTKC2/ymTkjIlzRoF/P5iX7P/CyUQ= X-Google-Smtp-Source: ADFU+vtRNh/CnYuOmX7XQ6blztMmya3gHuRe2maCm6tSJHR4CfbEGpATK3UNvo7WH6WaN85D5tZatA== X-Received: by 2002:a37:b002:: with SMTP id z2mr22556900qke.289.1585004856333; Mon, 23 Mar 2020 16:07:36 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id d19sm12255448qkc.14.2020.03.23.16.07.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 16:07:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Sean Turner In-Reply-To: Date: Mon, 23 Mar 2020 19:07:34 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> <35C34180-8890-4A7B-85C5-419D4D9586C8@vigilsec.com> <7620E876-DCA6-47B2-8EBE-15F4698971F8@sn3rd.com> To: Russ Housley X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Mon, 23 Mar 2020 23:07:40 -0000 Sorry that=E2=80=99s s/Signed-data/signed-data ;) > On Mar 13, 2020, at 2:24 PM, Russ Housley = wrote: >=20 > Fixed in my edit buffer, except I could not find "Singed-data" in the = document. >=20 > Russ >=20 >=20 >> On Mar 13, 2020, at 1:39 PM, Sean Turner wrote: >>=20 >> Russ, >>=20 >> This draft is pretty straightforward. Just some nits: >>=20 >> 0) abstract/s1: Because this draft just addressed signed-data and = authenticated-data right up front? >>=20 >> 1) s1 and s4.1: s/Singed-data/signed-data >>=20 >> 2) s.4.1: s/Authenticated-data/authenticated-data >>=20 >> 3) s6: s/Likewise there us not/Likewise there is not >>=20 >> spt >>=20 >>> On Mar 9, 2020, at 12:02 PM, Russ Housley = wrote: >>>=20 >>> I updated the section ong timestamps based on some comments from an = implementer. >>>=20 >>> Russ >>>=20 >>>=20 >>>> On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >>>>=20 >>>> Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection >>>> Author : Russ Housley >>>> Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt >>>> Pages : 8 >>>> Date : 2020-03-09 >>>>=20 >>>> Abstract: >>>> This document updates the Cryptographic Message Syntax (CMS) >>>> specified in RFC 5652 to ensure that algorithm identifiers are >>>> adequately protected. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >>>>=20 >>>> There are also htmlized versions available at: >>>> = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 >>>=20 >>> _______________________________________________ >>> Spasm mailing list >>> Spasm@ietf.org >>> https://www.ietf.org/mailman/listinfo/spasm >>=20 >=20 From nobody Mon Mar 23 16:12: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 4C78A3A0F06 for ; Mon, 23 Mar 2020 16:11:59 -0700 (PDT) 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 3y2AY_Qzg9eu for ; Mon, 23 Mar 2020 16:11:57 -0700 (PDT) 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 3CEB53A0F0E for ; Mon, 23 Mar 2020 16:11:57 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id p60so8278805qva.5 for ; Mon, 23 Mar 2020 16:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=KwQ8S3wvAqvpg8+AQg58c4rzRIQa7fWeUqjfrUaF7BM=; b=iSeQk4Q4rqvWthDxYsG6uPU5xtuXFc7GdHVVdy5+HXLsPWqpluGLjypvjLhbpwJWQ4 +NtJsWo0wtV1dOD4h/FokYiBuzt9Ge05qPscHr7APsLUnAOWhn1Y+yDGuxn7l41c+Y2p IcJ2fZflXNiTuqOWcVmOjmPjmPNlLiPtnfSE8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=KwQ8S3wvAqvpg8+AQg58c4rzRIQa7fWeUqjfrUaF7BM=; b=iA+RcUzLw8aOQ/8yyzbqeqShfWl8XhrIzSfx9Oju8w4LAsv3uGXwoUI0snqBAUtyEu 4Yh1kWkimNUjffEyNLxme9Nv/nAuR0BWnfHQdoZzsWdHy/mALWs7uKwBoRORnqdLZ27K BqBW+sNRLHg+clYXTkCGTsH3ACVZTU59LMRua/8fxKNOmCe/o4zBdAbNqTBpIqBZrjy2 vhNHWt4q0YY6h2R+EMhextW9MJU2KBDMuENtEiCrLyUdrWe2z3U6S7vGJQAv3+4+IxvP rTzXSpQOfszL4/mr7/P/Te40LeTfIL/DtnSvxkLAO0Yn+ipLgS82Ouj3imy0p0O3Kx+D 2QxQ== X-Gm-Message-State: ANhLgQ0euQjFAUFLpGlw0xrqIAu6RPiHI4onDdlh1LXYiFCsy5SpvWXM fx8zvfb+ONniz67JF4OZOCc6BOyNFec= X-Google-Smtp-Source: ADFU+vtTvt6J5jI6NxOdMrKF5t0evFL4UdrApH4ZuJKvYGkTBgxIIqb4mAW8roYUPtN9bKElSH+kWg== X-Received: by 2002:a05:6214:282:: with SMTP id l2mr16384733qvv.249.1585005115934; Mon, 23 Mar 2020 16:11:55 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id b189sm11613646qkc.104.2020.03.23.16.11.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 16:11:55 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Mon, 23 Mar 2020 19:11:53 -0400 References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <158376952262.5608.9742103984595025685@ietfa.amsl.com> Message-Id: <1DF99CFE-CA2D-441D-992F-758A14A1C2C9@sn3rd.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Mon, 23 Mar 2020 23:12:22 -0000 Russ, One other thing that I am curious about (i.e., I do not really have a = strong sense either way) is whether we need to rev the CMS version in = the signed-data and authenticated-data? I see there=E2=80=99s some text = in s3.4 about backward compatibility that basically says there might be = an issue here but it was implemented as as is specified in this draft so = there=E2=80=99s really not a problem. spt > On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection > Author : Russ Housley > Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt > Pages : 8 > Date : 2020-03-09 >=20 > Abstract: > This document updates the Cryptographic Message Syntax (CMS) > specified in RFC 5652 to ensure that algorithm identifiers are > adequately protected. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Mar 23 16:20: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 E6D2B3A0EF2 for ; Mon, 23 Mar 2020 16:20:32 -0700 (PDT) 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 1Ol__ej257I4 for ; Mon, 23 Mar 2020 16:20:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555BA3A0EF1 for ; Mon, 23 Mar 2020 16:20:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BB242300B23 for ; Mon, 23 Mar 2020 19:20:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1aBAVIYKRCFo for ; Mon, 23 Mar 2020 19:20:25 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 227303005D9; Mon, 23 Mar 2020 19:20:25 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <1DF99CFE-CA2D-441D-992F-758A14A1C2C9@sn3rd.com> Date: Mon, 23 Mar 2020 19:20:26 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <9954DC04-C2C7-445A-BBFF-A66EFEC3786A@vigilsec.com> References: <158376952262.5608.9742103984595025685@ietfa.amsl.com> <1DF99CFE-CA2D-441D-992F-758A14A1C2C9@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-update-alg-id-protect-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: Mon, 23 Mar 2020 23:20:33 -0000 Sean: I believe that the draft is documenting existing implementation = practice. The point of the READER note paragraph in Section 3.4. So, = unless we learn about someone that is not already following the = conventions in this draft, then I do not think that version number = changes are needed or even desired. Russ > On Mar 23, 2020, at 7:11 PM, Sean Turner wrote: >=20 > Russ, >=20 > One other thing that I am curious about (i.e., I do not really have a = strong sense either way) is whether we need to rev the CMS version in = the signed-data and authenticated-data? I see there=E2=80=99s some text = in s3.4 about backward compatibility that basically says there might be = an issue here but it was implemented as as is specified in this draft so = there=E2=80=99s really not a problem. >=20 > spt >=20 >> On Mar 9, 2020, at 11:58 AM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >>=20 >> Title : Update to the Cryptographic Message Syntax = (CMS) for Algorithm Identifier Protection >> Author : Russ Housley >> Filename : = draft-ietf-lamps-cms-update-alg-id-protect-01.txt >> Pages : 8 >> Date : 2020-03-09 >>=20 >> Abstract: >> This document updates the Cryptographic Message Syntax (CMS) >> specified in RFC 5652 to ensure that algorithm identifiers are >> adequately protected. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-update-alg-id-protec= t/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-lamps-cms-update-alg-id-protect-01 >> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-update-alg-id-p= rotect-01 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-update-alg-id-pro= tect-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Mar 25 06:24:05 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 04D303A0CBC; Wed, 25 Mar 2020 06:23:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158514263090.31132.1349360671533158279@ietfa.amsl.com> Date: Wed, 25 Mar 2020 06:23:50 -0700 Archived-At: Subject: [lamps] Limited Additional Mechanisms for PKIX and SMIME (lamps) WG Virtual Meeting: 2020-03-30 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: Wed, 25 Mar 2020 13:24:01 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group will hold a virtual interim meeting on 2020-03-30 from 10:30 to 12:00 America/New_York (14:30 to 16:00 UTC). Agenda: LAMPS WG Virtual Meeting Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Documents with the RFC Editor and IESG a) draft-ietf-lamps-5480-ku-clarifications (Sean) 3) Active Working Group Documents a) draft-ietf-lamps-header-protection-requirements (Alexey, Bernie) b) draft-ietf-lamps-cms-update-alg-id-protect (Russ) c) draft-ietf-lamps-rfc7030est-clarify (Michael, Thomas, Wei) d) draft-ietf-lamps-cmp-updates (Henk) e) draft-ietf-lamps-lightweight-cmp-profile (Henk, Steffen, David) 4) Wrap Up Information about remote participation: Remote participation information will be obtained at the time of approval From nobody Sat Mar 28 14:02: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 6B5273A060A for ; Sat, 28 Mar 2020 14:02:41 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 5JFTfvdr2q2S for ; Sat, 28 Mar 2020 14:02:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73FA43A05DE for ; Sat, 28 Mar 2020 14:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ED051300B13 for ; Sat, 28 Mar 2020 17:02:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pZk5ls5I4sI7 for ; Sat, 28 Mar 2020 17:02:35 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 43F7E3001A7 for ; Sat, 28 Mar 2020 17:02:35 -0400 (EDT) From: Russ Housley Content-Type: multipart/mixed; boundary="Apple-Mail=_926C84D0-29B5-4A77-BAE3-363899BC393C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 28 Mar 2020 17:02:36 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] WebEx Info for the Virtual Meeting on Monday, 30 March 2020 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, 28 Mar 2020 21:02:42 -0000 --Apple-Mail=_926C84D0-29B5-4A77-BAE3-363899BC393C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii LAMPS WG Virtual Meeting Monday, Mar 30, 2020 10:30 am Eastern Time (UTC-04:00) for 90 minutes Meeting number: 613 709 650 Password: LampsWG-2020Apr https://ietf.webex.com/ietf/j.php?MTID=3Dm19b1d7a9c8b3567f11a10c825d647240= Join by video system Dial 613709650@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 613 709 650 Etherpad: = https://etherpad.ietf.org:9009/p/notes-ietf-107-lamps?useMonospaceFont=3Dt= rue Slides: = https://datatracker.ietf.org/meeting/interim-2020-lamps-01/session/lamps Jabber: xmpp:lamps@jabber.ietf.org --Apple-Mail=_926C84D0-29B5-4A77-BAE3-363899BC393C Content-Disposition: attachment; filename=lamps-20200330.ics Content-Type: text/calendar; x-unix-mode=0644; name="lamps-20200330.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0APRODID:-//Microsoft=20Corporation//Outlook=2010.0=20= MIMEDIR//EN=0D=0AVERSION:2.0=0D=0AMETHOD:REQUEST=0D=0ABEGIN:VTIMEZONE=0D=0A= TZID:America/New_York=0D=0A= TZURL:http://tzurl.org/zoneinfo-outlook/America/New_York=0D=0A= X-LIC-LOCATION:America/New_York=0D=0ABEGIN:DAYLIGHT=0D=0A= TZOFFSETFROM:-0500=0D=0ATZOFFSETTO:-0400=0D=0ATZNAME:EDT=0D=0A= DTSTART:19700308T020000=0D=0ARRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D2SU=0D= =0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0ATZOFFSETFROM:-0400=0D=0A= TZOFFSETTO:-0500=0D=0ATZNAME:EST=0D=0ADTSTART:19701101T020000=0D=0A= RRULE:FREQ=3DYEARLY;BYMONTH=3D11;BYDAY=3D1SU=0D=0AEND:STANDARD=0D=0A= END:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0ADTSTAMP:20200328T205235Z=0D=0A= ATTENDEE;CN=3D"Russ=20= Housley";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:MAILTO:housley@vigilsec.com=0D= =0AORGANIZER;CN=3D"Cisco=20Webex":MAILTO:messenger@webex.com=0D=0A= DTSTART;TZID=3DAmerica/New_York:20200330T103000=0D=0A= DTEND;TZID=3DAmerica/New_York:20200330T121000=0D=0A= LOCATION:https://ietf.webex.com/ietf/j.php?MTID=3Dm19b1d7a9c8b3567f11a10c8= 25d647240=0D=0ATRANSP:OPAQUE=0D=0ASEQUENCE:1585428755=0D=0A= UID:721aee5d-6c60-4958-bad8-365bd5b6d569=0D=0ADESCRIPTION:\n\nJOIN=20= WEBEX=20= MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm19b1d7a9c8b3567f11a10c8= 25d647240\nMeeting=20number=20(access=20code):=20613=20709=20= 650\n\nMeeting=20password:=20LampsWG-2020Apr\n\n\n\nJOIN=20BY=20= PHONE\n1-650-479-3208=20Call-in=20toll=20number=20(US/Canada)\nTap=20= here=20to=20call=20(mobile=20phones=20only,=20hosts=20not=20supported):=20= tel:%2B1-650-479-3208,,*01*613709650%23%23*01*\n1-877-668-4493=20Call-in=20= toll=20free=20number=20(US/Canada)\nTap=20here=20to=20call=20(mobile=20= phones=20only,=20hosts=20not=20supported):=20= tel:1-877-668-4493,,*01*613709650%23%23*01*\n\nGlobal=20call-in=20= numbers\nhttps://ietf.webex.com/ietf/globalcallin.php?MTID=3Dmc071052b4cd6= 0c5f789c08a1fcb7859d\n\nToll-free=20calling=20= restrictions\nhttps://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\nJOI= N=20FROM=20A=20VIDEO=20SYSTEM=20OR=20APPLICATION\nDial=20= sip:613709650@ietf.webex.com\nYou=20can=20also=20dial=20173.243.2.68=20= and=20enter=20your=20meeting=20number.\n\n\nJoin=20using=20Microsoft=20= Lync=20or=20Microsoft=20Skype=20for=20Business\nDial=20= sip:613709650.ietf@lync.webex.com\n\n\n\nCan't=20join=20the=20meeting?=20= Contact=20support=20here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT=20= NOTICE:=20Please=20note=20that=20this=20Webex=20service=20allows=20audio=20= and=20other=20information=20sent=20during=20the=20session=20to=20be=20= recorded,=20which=20may=20be=20discoverable=20in=20a=20legal=20matter.=20= You=20should=20inform=20all=20meeting=20attendees=20prior=20to=20= recording=20if=20you=20intend=20to=20record=20the=20meeting.\n=0D=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:\n*=20{\n=20=20= =20=20padding:=200;=20=20=20=20margin:=200;}\ntable=20{\n=09= border-collapse:=20separate;=20width=20=3D100%;=09border:=200;=09= border-spacing:=200;}\n\ntr=20{\n=09line-height:=2018px;}\n\na,=20td=20= {\n=09font-size:=2014px;=09font-family:=20Arial;=09color:=20#333;=09= word-wrap:=20break-word;=09word-break:=20normal;=09padding:=20= 0;}\n\n.title=20{\n=09font-size:=2028px;}\n\n.image=20{\n=09width:=20= auto;=09max-width:=20auto;}\n\n.footer=20{\n=09width:=20604px;}\n\n.main=20= {\n\n}@media=20screen=20and=20(max-device-width:=20800px)=20{\n=09.title=20= {\n=09=09font-size:=2022px=20!important;=09}\n=09.image=20{\n=09=09= width:=20auto=20!important;=09=09max-width:=20100%=20!important;=09}\n=09= .footer=20{\n=09=09width:=20100%=20!important;=09=09max-width:=20604px=20= !important\n=09}\n=09.main=20{\n=09=09width:=20100%=20!important;=09=09= max-width:=20604px=20!important\n=09}\n}\n\n\n\n=09 \n=09\n=09=09\n=09=09=09\n\n\n\n=09=09=09\n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09=09 \n=09=09=09=09\n=09=09=09=09=09= \n=09=09=09=09\n=09=09=09
\n=09=09=09=09=09=09When=20it's=20time,=20join=20the=20Webex=20meeting=20= here.\n=09=09=09=09=09
\n=09=09=09=09=09=09Meeting=20number=20(access=20code):=20613=20709=20= 650\n=09=09=09=09=09
\n=09= =09=09\n=09=09=09=09\n=09=09=09=09=09\n=09=09=09=09\n=09=09=09=
\n=09=09=09=09=09=09= Host=20key:=20= 985093\n=09=09=09=09=09
\n=09=09=09
Meeting=20password:LampsWG-2020Apr
\n\n=20=20=20=20=20= =20=20=20\n=20=20=20=20=20=20=20=20=09 \n=09=09=09\n=09=09= =09=09\n=09=09=09=09=09\n=09=09=09=09=09=09\n=09=09=09=09=09=09=09= Join=20meeting\n=09=09=09=09=09=09= \n=09=09=09=09=09
\n=09=09=09=09\n=09=09=09\n=09=09= \n\n=20\n 
 
\n\n =20
Join=20by=20phone=20 =20
1-650-479-3208=20= Call-in=20toll=20number=20(US/Canada)=20 =20
1-877-668-4493=20= Call-in=20toll=20free=20number=20(US/Canada)=20 =20
Global=20= call-in=20numbers  |  Toll-free=20= calling=20restrictions =20


\n\n 
\n\nJoin=20from=20a=20video=20system=20or=20= application
Dial=20613709650@ietf.webex.com =20
You=20can=20also=20dial=20= 173.243.2.68=20and=20enter=20your=20meeting=20number.=20 =20=
 =20
\n\nJoin=20using=20Microsoft=20Lync=20or=20Microsoft=20Skype=20for=20= BusinessDial=20613709650.ietf@lync.webex.com= \n\n=09=09=09\n=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20 \n=09=09=09=09= \n=09=09=09=09=09Need=20= help?=20Go=20to=20http://help.webex.com\n=09=09=09=09=09\n=09= =09=09=09\n=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 \n=09=09=09\n=09=09= \n=09\n\n=0D=0ASUMMARY:LAMPS=20WG=0D=0APRIORITY:5=0D=0A= CLASS:PUBLIC=0D=0ABEGIN:VALARM=0D=0ATRIGGER:-PT5M=0D=0AACTION:DISPLAY=0D=0A= DESCRIPTION:Reminder=0D=0AEND:VALARM=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D= =0A= --Apple-Mail=_926C84D0-29B5-4A77-BAE3-363899BC393C-- From nobody Mon Mar 30 07:53: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 6B3B03A16FF; Mon, 30 Mar 2020 07:52:51 -0700 (PDT) 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=[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 y1yAyx6nNdT5; Mon, 30 Mar 2020 07:52:50 -0700 (PDT) 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 BD3A73A16FC; Mon, 30 Mar 2020 07:52:49 -0700 (PDT) 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 02UEqU9K002071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 10:52:33 -0400 Date: Mon, 30 Mar 2020 07:52:29 -0700 From: Benjamin Kaduk To: RFC Errata System , spasm@ietf.org Cc: kent@bbn.com, stefan@aaa-sec.com, justin.cranford@entrustdatacard.com, pkix@ietf.org Message-ID: <20200330145229.GW50174@kduck.mit.edu> References: <20191112204840.35508F40737@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191112204840.35508F40737@rfc-editor.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Technical Errata Reported] RFC7030 (5904) 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 Mar 2020 14:52:52 -0000 Forwarding to the LAMPS WG list since the original seems to have not made it into the PKIX archives. -Ben On Tue, Nov 12, 2019 at 12:48:40PM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC7030, > "Enrollment over Secure Transport". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5904 > > -------------------------------------- > Type: Technical > Reported by: Justin Cranford > > Section: 4.1.3 > > Original Text > ------------- > Content-Transfer-Encoding: base64 > > Corrected Text > -------------- > Transfer-Encoding: base64 > > Notes > ----- > Content-Transfer-Encoding is not a valid HTTP header. RFC 7030 is not compliant with RFC 2616. > > - "MIME Content-Transfer-Encoding: base64" => Base64 Basic with CRLFs > - "HTTP Transfer-Encoding: base64" => Base64 Basic without CRLFs > > This is traceable from RFC 7030 (EST) through RFC 2818 (TLS) to RFC 2616 (HTTP). > > - RFC 7030 (EST): EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) [RFC2818] > - RFC 2818 (TLS): HTTP [RFC2616] was originally used in the clear on the Internet. > - RFC 2616 (HTTP): HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. > - RFC 2616 (HTTP): HTTP/1.1 introduces the Transfer-Encoding header field (section 14.41). > > RFC 7030 sections affected are: > > - All references to Content-Transfer-Encoding are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, A.1, A.2, A.3, and A.4. > - All references to RFC 2045 are not valid: Sections 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1. > - All references to "base64" need to be updated or removed: Sections 3.5, 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1. > > RFC 7030 fix options: > > Option #1: Change all references from Content-Transfer-Encoding to Transfer-Encoding. A caveat is that "base64" has a different meaning in HTTP (no CRLFs) vs MIME (includes CRLFs). > > Option #2: Remove all references to Content-Transfer-Encoding and base64. Responses would be transmitted as binary. This allows the response to be transported more efficiently without base64 size bloat, and it allows optional use of Content-Length header so the response can be parsed more efficiently knowing the length ahead of time. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7030 (draft-ietf-pkix-est-09) > -------------------------------------- > Title : Enrollment over Secure Transport > Publication Date : October 2013 > Author(s) : M. Pritikin, Ed., P. Yee, Ed., D. Harkins, Ed. > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Mon Mar 30 07:58: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 E990B3A0985 for ; Mon, 30 Mar 2020 07:58:01 -0700 (PDT) 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=[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 UKuL9kS0Ng-A for ; Mon, 30 Mar 2020 07:57:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC1F3A098B for ; Mon, 30 Mar 2020 07:57:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2237C3897E for ; Mon, 30 Mar 2020 10:56:20 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 95ACF16B for ; Mon, 30 Mar 2020 10:57:48 -0400 (EDT) From: Michael Richardson to: spasm@ietf.org In-Reply-To: <158345858645.14723.3002052789783805901@ietfa.amsl.com> References: <158345858645.14723.3002052789783805901@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] next steps for draft-ietf-lamps-rfc7030est-clarify-02.txt (fwd) Michael Richardson: next steps for draft-ietf-lamps-rfc7030est-clarify-02.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, 30 Mar 2020 14:58:03 -0000 --=-=-= Content-Type: text/plain I have asked Justin Cranford at entrustdatacard for comments on the document. The email with the summary from March 6 is at: https://mailarchive.ietf.org/arch/msg/spasm/-frEPin8InEzEv2CQgPqtYbj-qw/ There are a few questions in that email. The "big" question was: >> b) https://www.rfc-editor.org/errata/eid5926 >> >> asks to have the Examples updates. >> c) https://www.rfc-editor.org/errata/eid5779 >> >> points out the extra before ";", which should be tolerated, but not >> required. This could updated with (b) above, I think. We could repeat the example and fix it in the Update. If that suits the WG, I will copy and paste, fixing the space. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6CCOwACgkQgItw+93Q 3WXXrAgAqG+mIUpbi4mpTDeRdFmDv6v7s30h4E0Cw4qv7rL5MrpKtdlGwWsWP9HW g9r7qTwEg75q1Ns+rxGm/iWr6QkD2cuI08sgfGluCiljR9+99eAlVid4oivcc5Y+ v7zk0ZekcZNBGlKwlHTe6J6723JkgY4Yyyg0AW98INOTmueKB2Ew6v9wZa+Iy/9d vw0MhPRoV3x/0KLr3LPkpCvwB4Fp1gpGwvSZtcNm9S42wMkITUBCDW4OlzA7meQ/ Lethl2juR5dpA+96zHDdX1tjLT8UkIxvhZMCzdB1MOLrAxhmQ/2ZuyUr0F2+GnpV aVhCZ3Ujnorq0H2Fi4bfil7By984Mg== =UK9j -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 30 09:03: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 715863A184C for ; Mon, 30 Mar 2020 09:03:38 -0700 (PDT) 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 aGpRZ13xQNG1 for ; Mon, 30 Mar 2020 09:03:36 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF14F3A1857 for ; Mon, 30 Mar 2020 09:03:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6152C300AA8 for ; Mon, 30 Mar 2020 12:03:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ST1fQy0yKTPC for ; Mon, 30 Mar 2020 12:03:31 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id F03D1300A4B for ; Mon, 30 Mar 2020 12:03:30 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Mon, 30 Mar 2020 12:03:32 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Corrected slides for draft-ietf-lamps-cms-update-alg-id-protect-01 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 Mar 2020 16:03:42 -0000 h= ttps://datatracker.ietf.org/doc/slides-interim-2020-lamps-01-sessa-cms-upd= ate-for-algorithm-identifier-protection/ Sorry that the old slides were posted for the meeting. The updated ones = have now been posted. Please post any questions that the new slides = might raise on this thread. Russ From nobody Mon Mar 30 09:04: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 6303C3A1745; Mon, 30 Mar 2020 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYNc81SxqDrN; Mon, 30 Mar 2020 08:14:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374823A1738; Mon, 30 Mar 2020 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3032; q=dns/txt; s=iport; t=1585581259; x=1586790859; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=BeE/UYqKYpcVpv/I1dinEi8RYBr1gkdR0cu2ZPJbGaM=; b=WuhTeZf8D0deVkIKd6wF+Ql5ZuHjOAfSZqN2J8FPuqDs33Esa3x6BhGL 4FsVrLbPiILjPdEuInDQlxkXHXGZeLgbv9nwzpmvPQzxMzhm2bMCMSG3j gzCrFc4bcTH2yGBnhT/pojkQzfzU7L/1ovun27zjgikwiRUY6RHav+B7e Y=; X-IronPort-AV: E=Sophos;i="5.72,324,1580774400"; d="scan'208";a="22575211" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2020 15:14:17 +0000 Received: from dhcp-10-61-104-254.cisco.com (dhcp-10-61-104-254.cisco.com [10.61.104.254]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 02UFEGOh004963 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2020 15:14:16 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Eliot Lear In-Reply-To: <20200330145229.GW50174@kduck.mit.edu> Date: Mon, 30 Mar 2020 17:14:16 +0200 Cc: RFC Errata System , spasm@ietf.org, stefan@aaa-sec.com, justin.cranford@entrustdatacard.com, kent@bbn.com, pkix@ietf.org, Michael Richardson , "Max Pritikin (pritikin)" , "Fries, Steffen" , Panos Kampanakis Content-Transfer-Encoding: quoted-printable Message-Id: <8CEE9B1C-42A1-4601-9E6D-B9786D947B67@cisco.com> References: <20191112204840.35508F40737@rfc-editor.org> <20200330145229.GW50174@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.104.254, dhcp-10-61-104-254.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: X-Mailman-Approved-At: Mon, 30 Mar 2020 09:04:45 -0700 Subject: Re: [lamps] [pkix] [Technical Errata Reported] RFC7030 (5904) 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 Mar 2020 15:14:22 -0000 > On 30 Mar 2020, at 16:52, Benjamin Kaduk wrote: >=20 > Forwarding to the LAMPS WG list since the original seems to have not = made > it into the PKIX archives. >=20 > -Ben >=20 > On Tue, Nov 12, 2019 at 12:48:40PM -0800, RFC Errata System wrote: >> The following errata report has been submitted for RFC7030, >> "Enrollment over Secure Transport". >>=20 >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid5904 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Justin Cranford >>=20 >> Section: 4.1.3 >>=20 >> Original Text >> ------------- >> Content-Transfer-Encoding: base64 >>=20 >> Corrected Text >> -------------- >> Transfer-Encoding: base64 >>=20 >> Notes >> ----- >> Content-Transfer-Encoding is not a valid HTTP header. RFC 7030 is not = compliant with RFC 2616. >>=20 >> - "MIME Content-Transfer-Encoding: base64" =3D> Base64 Basic with = CRLFs >> - "HTTP Transfer-Encoding: base64" =3D> Base64 Basic without CRLFs >>=20 >> This is traceable from RFC 7030 (EST) through RFC 2818 (TLS) to RFC = 2616 (HTTP). >>=20 >> - RFC 7030 (EST): EST specifies how to transfer messages securely via = HTTP over TLS (HTTPS) [RFC2818] >> - RFC 2818 (TLS): HTTP [RFC2616] was originally used in the clear on = the Internet. >> - RFC 2616 (HTTP): HTTP does not use the Content-Transfer-Encoding = (CTE) field of RFC 2045. >> - RFC 2616 (HTTP): HTTP/1.1 introduces the Transfer-Encoding header = field (section 14.41). >>=20 >> RFC 7030 sections affected are: >>=20 >> - All references to Content-Transfer-Encoding are not valid: Sections = 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, A.1, A.2, A.3, and A.4. >> - All references to RFC 2045 are not valid: Sections 4.1.3, 4.3.1, = 4.3.2, 4.4.2, 4.5.2, and 7.1. >> - All references to "base64" need to be updated or removed: Sections = 3.5, 4.1.3, 4.3.1, 4.3.2, 4.4.2, 4.5.2, and 7.1. >>=20 >> RFC 7030 fix options: >>=20 >> Option #1: Change all references from Content-Transfer-Encoding to = Transfer-Encoding. A caveat is that "base64" has a different meaning in = HTTP (no CRLFs) vs MIME (includes CRLFs). For interoperability purposes in the erratum, we might advise that both = should be tolerated, but one needs to be preferred. Adding Max, = Michael, Stefan, and Panos who have implemented, for discussion. >>=20 >> Option #2: Remove all references to Content-Transfer-Encoding and = base64. Responses would be transmitted as binary. This allows the = response to be transported more efficiently without base64 size bloat, = and it allows optional use of Content-Length header so the response can = be parsed more efficiently knowing the length ahead of time. >>=20 If this is the direction, then I would hold for update because more work = would need to be done, and it would not be interoperable with existing = implementations. Elio= From nobody Mon Mar 30 09:11: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 826723A1888 for ; Mon, 30 Mar 2020 09:11:12 -0700 (PDT) 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 SfbwY7S8pio7 for ; Mon, 30 Mar 2020 09:11:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA66A3A187E for ; Mon, 30 Mar 2020 09:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6F587300B0D for ; Mon, 30 Mar 2020 12:11:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yZGeMsW6g_Zo for ; Mon, 30 Mar 2020 12:11:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 61822300A4B for ; Mon, 30 Mar 2020 12:11:07 -0400 (EDT) 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.11\)) Message-Id: <63B58892-60CB-42C9-8168-E5476E2F40CB@vigilsec.com> Date: Mon, 30 Mar 2020 12:11:08 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] WG Last Call for draft-ietf-lamps-rfc7030est-clarify-02 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 Mar 2020 16:11:13 -0000 This is the LAMPS WG Last Call for "Clarification of Enrollment over = Secure Transport (EST): transfer encodings and ASN.1=E2=80=9D = . Please review the document = and send your comments to the list by 19 April 2020. This is longer = than usual to accommodate the vast number of virtual interim sessions = that are taking place right now. The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc7030est-clarify/ Thanks, Russ & Tim From nobody Mon Mar 30 09:46: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 7F55B3A1868 for ; Mon, 30 Mar 2020 09:46:06 -0700 (PDT) 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=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 4JUMsIgA9h61 for ; Mon, 30 Mar 2020 09:46:05 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 97CBB3A1867 for ; Mon, 30 Mar 2020 09:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1585586764; d=isode.com; s=june2016; i=@isode.com; bh=kJUivldkVp9MYhcxTIUy0yk7BEZHg4pCwho8ZTl7dS4=; 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=mZI0QC0TqCjyxJCaafdoXB2Cp8TPUCdjrCx++XusAx+ewj+axE76PAliUk/kIBsk9VGnZJ HzUqTQt6KKITev3kCQNzbTKHL0K+keIaeFHPfnFKQopK0TibvsKmHQqKNRKNtBOgLw1GKn 9QAY/gyD1WakwDAY9VH7zVwx0Yls2Aw=; Received: from [192.168.1.222] (host81-151-37-252.range81-151.btcentralplus.com [81.151.37.252]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 30 Mar 2020 17:46:04 +0100 To: Russ Housley Cc: LAMPS WG From: Alexey Melnikov Message-ID: Date: Mon, 30 Mar 2020 17:45:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: [lamps] Review of draft-ietf-lamps-cms-update-alg-id-protect-01 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 Mar 2020 16:46:07 -0000 Hi Russ, I just read your draft and I think it is well written and is ready for=20 publication. You can treat my reply as +1 for WGLC. Just one small=20 editorial nit: 6.=C2=A0 Security Considerations The last sentence of the 2nd para reads: =C2=A0=C2=A0 Likewise there us not currently I think you meant something like "Likewise there is currently no" above? =C2=A0=C2=A0 protection mechanism for the algorithm identifiers used in the =C2=A0=C2=A0 authenticated-enveloped-data content type defined in [RFC5083]= . Best Regards, Alexey From nobody Mon Mar 30 10:28: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 A0B7F3A0867; Mon, 30 Mar 2020 10:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0W9u_8Fvish; Mon, 30 Mar 2020 10:28:03 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBEB3A07C5; Mon, 30 Mar 2020 10:28:03 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 16F983897B; Mon, 30 Mar 2020 13:26:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AF0D16B; Mon, 30 Mar 2020 13:27:58 -0400 (EDT) From: Michael Richardson To: spasm@ietf.org, stefan@aaa-sec.com, justin.cranford@entrustdatacard.com, kent@bbn.com, "Max Pritikin \(pritikin\)" , "Fries\, Steffen" , Panos Kampanakis CC: pkix@ietf.org Reply-To: spasm@ietf.org In-Reply-To: <8CEE9B1C-42A1-4601-9E6D-B9786D947B67@cisco.com> References: <20191112204840.35508F40737@rfc-editor.org> <20200330145229.GW50174@kduck.mit.edu> <8CEE9B1C-42A1-4601-9E6D-B9786D947B67@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] [pkix] [Technical Errata Reported] RFC7030 (5904) 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 Mar 2020 17:28:07 -0000 --=-=-= Content-Type: text/plain Eliot Lear wrote: >> Option #1: Change all references from Content-Transfer-Encoding to >> Transfer-Encoding. A caveat is that "base64" has a different meaning in >> HTTP (no CRLFs) vs MIME (includes CRLFs). > For interoperability purposes in the erratum, we might advise that both > should be tolerated, but one needs to be preferred. Adding Max, > Michael, Stefan, and Panos who have implemented, for discussion. Unless someone with a deployed product comes forward claiming that they accept non-base64 encoded content when there is no CTE header *AND* they have interoperated with some other product, then the feedback from implementers that I was able to reach last spring is that they: 1) didn't insert CTE, (and ignored it), because it was junk. 2) base64 encoded all content. Changing it to Transfer-Encoding does not make sense. {This is in the archives somewhere} >> Option #2: Remove all references to Content-Transfer-Encoding and >> base64. Responses would be transmitted as binary. This allows the >> response to be transported more efficiently without base64 size bloat, >> and it allows optional use of Content-Length header so the response can >> be parsed more efficiently knowing the length ahead of time. >> > If this is the direction, then I would hold for update because more > work would need to be done, and it would not be interoperable with > existing implementations. This would be an incompatible change on the wire. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl6CLB4ACgkQgItw+93Q 3WUbJwf/dIfwjnffjY9RDLDnm7F14mqyb/8eL02szMNueqsbG6z9dzm8bwPWDR8x E68guHcUAS1PRJHAVhGwERPdS7ggbiqUp5dyLjDwy4oojDgAK2ia2eefHcA5QiJP M44CH5R2+YU+rQNhxszqsCWW3F5ZNPP0AcH8pK9yCr7Iy8BwEnw+wUO0ATVQ/ZOq IceH++STLphM6H8UIT+dl4M4IadPt5tHYvMme6afmVz0b/Hml3DkubtCufljnwNw 0vd8m1DzV0YjVHFDGQd4LtjneU3aYyKbg1s8DdrqBky7YBCiYP/xGQGSxnrDuM0i HXvsveUrAyB96LBfAsFBc2SQaGpzQg== =LsLV -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 30 11:41: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 335A83A0E0B for ; Mon, 30 Mar 2020 11:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 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, 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 iWVY0HR6Gsoj for ; Mon, 30 Mar 2020 11:41:29 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.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 1D4653A0E05 for ; Mon, 30 Mar 2020 11:41:28 -0700 (PDT) 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 02UIbs6t008539; Mon, 30 Mar 2020 19:40:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=BdNjVlZ90w496yWqIdZ4glAkhbgEy7ecQdCDMXxFPG4=; b=ex4OCvmYOjeK3zc2JWIa1mjhop1VkNkwYsfJH4DiogppxMUqCIg9iA91FyxFAipwnY2Y GDr3AmQ1GejcLA9hIvF1in4GzZlwndrWmW3Oe0rP/kVb34qA3YJCIj/NXg3ge5L8DLKy mij1MXw0K4F8IllVJGR/kdkiejQvWcbQmQToWZgqqS0ra5ZfUaUiIFuPnWk13ixVc4tL c+NhBYF6XmPSNwWr5yYJpN+pckWz2vvDIzkQcNpS29F7SRIpu0M5m6HrUQ57y9vPGnjk r3GM0TlwxxPmC9vWkoI2+8028XYbYZVMyXlk/QUhssMv2lDqKa0GekfLv9k/IbjRf73x Hg== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 301xqbhqj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 19:40:28 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 02UIX9ME019864; Mon, 30 Mar 2020 14:40:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint7.akamai.com with ESMTP id 3028d8f80y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 14:40:27 -0400 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; Mon, 30 Mar 2020 13:40:26 -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 mapi id 15.00.1497.006; Mon, 30 Mar 2020 13:40:21 -0500 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] WG Last Call for draft-ietf-lamps-rfc7030est-clarify-02 Thread-Index: AQHWBq3YyCAIs7ZgJECETWDi/VMFJqhhiMGA Date: Mon, 30 Mar 2020 18:40:20 +0000 Message-ID: <29333D1C-ED3B-4D31-B004-F47FB6E17868@akamai.com> References: <63B58892-60CB-42C9-8168-E5476E2F40CB@vigilsec.com> In-Reply-To: <63B58892-60CB-42C9-8168-E5476E2F40CB@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.118.63] Content-Type: text/plain; charset="utf-8" Content-ID: <1FEB987CED20A440BF30B2E5DE4BD14B@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003300157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_07:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 spamscore=0 clxscore=1015 adultscore=0 impostorscore=0 malwarescore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300157 Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-rfc7030est-clarify-02 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 Mar 2020 18:41:30 -0000 SnVzdCByZS1yZWFkIGl0LiBTaGlwIGl0Lg0KDQrvu79PbiAzLzMwLzIwLCAxMjoxMSBQTSwgIlJ1 c3MgSG91c2xleSIgPGhvdXNsZXlAdmlnaWxzZWMuY29tPiB3cm90ZToNCg0KICAgIFRoaXMgaXMg dGhlIExBTVBTIFdHIExhc3QgQ2FsbCBmb3IgIkNsYXJpZmljYXRpb24gb2YgRW5yb2xsbWVudCBv dmVyIFNlY3VyZSBUcmFuc3BvcnQgKEVTVCk6IHRyYW5zZmVyIGVuY29kaW5ncyBhbmQgQVNOLjHi gJ0gPGRyYWZ0LWlldGYtbGFtcHMtcmZjNzAzMGVzdC1jbGFyaWZ5LTAyPi4gIFBsZWFzZSByZXZp ZXcgdGhlIGRvY3VtZW50IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgMTkg QXByaWwgMjAyMC4gIFRoaXMgaXMgbG9uZ2VyIHRoYW4gdXN1YWwgdG8gYWNjb21tb2RhdGUgdGhl IHZhc3QgbnVtYmVyIG9mIHZpcnR1YWwgaW50ZXJpbSBzZXNzaW9ucyB0aGF0IGFyZSB0YWtpbmcg cGxhY2UgcmlnaHQgbm93Lg0KICAgIA0KICAgIFRoZSBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGUg ZG9jdW1lbnQgaXMgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1s YW1wcy1yZmM3MDMwZXN0LWNsYXJpZnkvDQogICAgDQogICAgVGhhbmtzLA0KICAgIFJ1c3MgJiBU aW0NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIFNwYXNtIG1haWxpbmcgbGlzdA0KICAgIFNwYXNtQGlldGYub3JnDQogICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KICAgIA0KDQo= From nobody Tue Mar 31 11:03: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 7864B3A2607 for ; Tue, 31 Mar 2020 11:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 rwFLiUe6spPq for ; Tue, 31 Mar 2020 11:03:56 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0210A3A2605 for ; Tue, 31 Mar 2020 11:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6E859300A51 for ; Tue, 31 Mar 2020 14:03:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NWvw-FaJtC92 for ; Tue, 31 Mar 2020 14:03:52 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 2E5EF3001CC for ; Tue, 31 Mar 2020 14:03:52 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <2FEB1904-2275-4CAE-9263-2196E568ADBC@vigilsec.com> Date: Tue, 31 Mar 2020 14:03:53 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] draft-ietf-lamps-lightweight-cmp-profile-01, section 5.1.6.1 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, 31 Mar 2020 18:03:58 -0000 5.1.6.1 includes this text: kekid REQUIRED keyIdentifier REQUIRED -- MUST contain the same value as the senderKID in the respective -- request messages keyEncryptionAlgorithm REQUIRED -- MUST be id-PasswordBasedMac PBMParameter REQUIRED salt REQUIRED I find this difficult. Using id-PasswordBasedMac as a = keyEncryptionAlgorithm algorithm identifier is a problem. The OID tells = the implementation how to parse the parameter structure, but it also = tells the implementation what processing steps are needed. It works for = the structure, but I think it will be a big problem for the processing = steps. This is made worse by: "This key management technique can be = applied in combination with the PKI management operation specified in = Section 5.1.4 using MAC protected CMP messages." This means that = id-PasswordBasedMac would be used to indicate two different sets of = processing steps in the same message. I recommend the assignment of a different OID for use as a = keyEncryptionAlgorithm. Russ From nobody Tue Mar 31 17:19:03 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 0A34D3A0E11; Tue, 31 Mar 2020 17:19:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158570034097.28459.13613334674786871153@ietfa.amsl.com> Date: Tue, 31 Mar 2020 17:19:01 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-03.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: Wed, 01 Apr 2020 00:19:01 -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 : Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information Authors : Tadahiko Ito Sean Turner Filename : draft-ietf-lamps-5480-ku-clarifications-03.txt Pages : 3 Date : 2020-03-31 Abstract: This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-03 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarifications-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-5480-ku-clarifications-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 31 17:20: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 47FB93A0E0A for ; Tue, 31 Mar 2020 17:19:59 -0700 (PDT) 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 BFcaVulXq4mm for ; Tue, 31 Mar 2020 17:19:57 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 0ACAB3A0E09 for ; Tue, 31 Mar 2020 17:19:51 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id y25so1280832qtv.7 for ; Tue, 31 Mar 2020 17:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=gr4ToJFnbj/dCv++DPt0N9AwJAxfOIHDeCnW/n4ojaM=; b=lajC8UE9QLvI35QlX2X8ODPkt2zhANhYDZ/JYHRhWAsin1Rh1glRSaQV7e2M2XaS7G VvCTZGzLuYo6Cm37oLF4oQg8lMwzR7t9IspZ2gALLGBmYR9ovyWoWG/EEmgQVGRsvb8P O7ecioHNzqXiSlEP+DIdlTW7JKB/Xp/Cnuzog= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=gr4ToJFnbj/dCv++DPt0N9AwJAxfOIHDeCnW/n4ojaM=; b=jN9H8GBYskXnCZK18f1bnzd8o8wkzVP9Bu2JmueDE3JMN7vIzhZW9nLgT4tU202w4R wg0Ij/rlJakFImj0ROy0h2/SjS+7Ms5zZ1kLvOaOT+a5MDwpMXvZRsf8S/UWe6/Q0hSr G84hgr86kj475a4oTrvyx+0ulyu6IdJ9x5oZni7/hDMVrBgayZHfOnrcTHGhAs8iSEgp x2CjxfHFGryoxk+AcwBXHG2u9W4NoHtSIg2f/6k5/rwgQHvCxzVde93yrZuabqox5t31 YSuz0pG338wSeVDqlATdfhxU3odeoG3yUcshi4FnM0uzBXSggIZa0KZqhbWjYZ9sGDwA S7Nw== X-Gm-Message-State: ANhLgQ1UNfCwGKBUFgPmvmw7nvIauMUTmBxsi5WN/2e1Le2AX2WK1GF5 iGCgRBg+9bwycJYFZibsJvQb3o1lOnc= X-Google-Smtp-Source: ADFU+vuIGe69NrV2pmGwP+bhhHfL6AcYp8jWpX2lDM9AbA896Iy/H7rGplf0eKGU1IGTS7ZoiTebVQ== X-Received: by 2002:ac8:470c:: with SMTP id f12mr7778550qtp.135.1585700390080; Tue, 31 Mar 2020 17:19:50 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id l13sm365929qtu.66.2020.03.31.17.19.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Mar 2020 17:19:49 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 31 Mar 2020 20:19:48 -0400 References: <158570034097.28459.13613334674786871153@ietfa.amsl.com> To: LAMPS WG , Roman Danyliw In-Reply-To: <158570034097.28459.13613334674786871153@ietfa.amsl.com> Message-Id: <05562FE7-4D73-4E6E-8A63-67D553ABEE7C@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-03.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: Wed, 01 Apr 2020 00:19:59 -0000 This makes the minor edit noted in Ben=E2=80=99s review. Roman - it=E2=80=99s ready! spt > On Mar 31, 2020, at 20:19, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information > Authors : Tadahiko Ito > Sean Turner > Filename : draft-ietf-lamps-5480-ku-clarifications-03.txt > Pages : 3 > Date : 2020-03-31 >=20 > Abstract: > This document updates RFC 5480 to specify semantics for the > keyEncipherment and dataEncipherment key usage bits when used in > certificates that support Elliptic Curve Cryptography. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm