Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT)

Kent Watsen <kent+ietf@watsen.net> Fri, 21 January 2022 11:44 UTC

Return-Path: <0100017e7c73a251-5c626ec1-4fee-46ee-b674-bd5efdfab6f6-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663963A1CCF; Fri, 21 Jan 2022 03:44:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 GHJePRXTBmob; Fri, 21 Jan 2022 03:44:25 -0800 (PST)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F523A1CD2; Fri, 21 Jan 2022 03:44:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1642765460; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=ojCa6+pV0NK1t6HD1X96cZnSFw6Oqf7NXGRLtbmW6cw=; b=B0k2dlHYoGRdYIuYEHge8KSdfJ16Ffwjx5Z2wouacrWRupkYxSbHHt9bkAjqAMvS yiThCz+iptjRsb1sxvuMkDO5H+YJLVnfWsoLa7ZBSM5PVuRJr9dUpb9/Pv5U/QrfcFp PNWW/N2cNCwwTAN0iE/7bkJkMpCu/gRzIbO0R/nw=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20211225032223.GG11486@mit.edu>
Date: Fri, 21 Jan 2022 11:44:20 +0000
Cc: "netconf@ietf.org" <netconf@ietf.org>, draft-ietf-netconf-sztp-csr@ietf.org, IESG <iesg@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100017e7c73a251-5c626ec1-4fee-46ee-b674-bd5efdfab6f6-000000@email.amazonses.com>
References: <163952699208.6437.8936066509149136808@ietfa.amsl.com> <0100017dde220d3d-4be5f8d7-c4a8-4f45-81d9-0c80bfac77a2-000000@email.amazonses.com> <20211222223214.GT11486@mit.edu> <0ED98E8C-611D-4303-9F1D-BDC1EAFD73AA@vigilsec.com> <20211225032223.GG11486@mit.edu>
To: Russ Housley <housley@vigilsec.com>, Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.01.21-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lVsrM687Eae2vV1pK3wQUJdlcnA>
Subject: Re: [netconf] Benjamin Kaduk's No Objection on draft-ietf-netconf-sztp-csr-12: (with COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2022 11:44:30 -0000

[top-posting for clarity]

Russ and Ben,

Picking up on this thread, it looks like a coin-flip to me.  Should we have:

NEW:   PKIData contains one cmsSequence element and no
          controlSequence, reqSequence, or otherMsgSequence
          elements. […]

NEWER:   PKIData contains one cmsSequence element and no
          reqSequence or otherMsgSequence elements. […]

Or something else?

Thanks,
Kent



> On Dec 24, 2021, at 10:22 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Hi Russ,
> 
> On Thu, Dec 23, 2021 at 01:12:18PM -0500, Russ Housley wrote:
>> Ben:
>> 
>> Responding to just one comment in this message ...
>> 
>>>>>              TaggedContentInfo and it includes a bodyPartID element
>>>>>              and a contentInfo.  The contentInfo is a SignedData
>>>>>              encapsulating a PKIData with one reqSequence element
>>>>>              and no cmsSequence or otherMsgSequence elements. The
>>>>>              reqSequence is the TaggedRequest and it is the tcr
>>>>>              CHOICE. The tcr is the TaggedCertificationRequest and
>>>>>              it a bodyPartId and the certificateRequest elements.
>>>>>              [...]
>>>>> 
>>>>> ... since this reqSequence seems to refer to the PKIData inside the
>>>>> SignedData in the contentInfo in the cmsSequence.  Should we say
>>>>> anything about the presence/absence of reqSequence in the toplevel
>>>>> PKIData (since we do in the other two cases)?
>>>> 
>>>> Yes, the authors propose:
>>>> 
>>>> OLD: […]
>>>> 
>>>> NEW:   PKIData contains one cmsSequence element and no
>>>>           controlSequence, reqSequence, or otherMsgSequence
>>>>           elements. […]
>>>> 
>>>> 
>>>> Good?
>>> 
>>> I don't think we mention controlSequence anywhere else at present (though
>>> it is mentioned in the "NEW" text above).  I don't think the omission
>>> seemed noteworthy when I was doing my original review, so my primary
>>> consideration here is just that we give it consistent treatment everywhere
>>> (in terms of whether or not we mention it).
>> 
>> When looking at the text to address your comment, I could see not a role for controlSequence in this situation; however, I think there might possibly be a role in some of the other places.  For that reason, I thik it should be allowable in other places.  That is, the text should not exclude it.  If for consistency, you would rather not exclude controlSequence anywhere, I am fine with that too.
> 
> I have no strong preference here.  If you have looked at all the cases and
> think this one is "different enough" that controlSequence is not needed, I
> do not object to having it mentioned here.
> Thanks,
> 
> Ben
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf