Re: [netconf] AD review of draft-ietf-netconf-sztp-csr

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 21 June 2021 15:12 UTC

Return-Path: <rwilton@cisco.com>
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 881B93A0A3E; Mon, 21 Jun 2021 08:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.996
X-Spam-Level:
X-Spam-Status: No, score=-9.996 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g0Idy6uM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fxPYsFrF
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K5nH9OjmO9o; Mon, 21 Jun 2021 08:12:09 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC0D3A0A38; Mon, 21 Jun 2021 08:12:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14398; q=dns/txt; s=iport; t=1624288328; x=1625497928; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=URhdguD0g/EHnOTPEt+3BnN7HE5IX2zQ5JhlGQIOEts=; b=g0Idy6uMhVgB7jtFZDwZQ8DLc7rIRYtRm2jzGQWK5M0IFYwqEYOl1Bsa fdR2aCZOofRmYiN5O+BkfTJ86nBV5mfsvVXsxcnpxNq2ipWJecbOsJ9hI 3rLY506NHt4HfNSxfKNvJ3qnvYHbd+0PS+zhdshOZOTD3v+LqO22UoWr5 M=;
X-IPAS-Result: A0DPAgDjq9Bgl4cNJK1RCYEJgVeBU1F+WjcxC4Q9g0gDhTmIbAOPW4pCgS6BJQNUCwEBAQ0BAT8CBAEBhFACF4JWAiU2Bw4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohTsFKA2GRQEBAQMBEhERDAEBKQ4BCwQCAQgRBAEBAwImAgICMBUICAEBBA4FCBqCTwGCVQMOIQEDmkcBgToCih96gTKBAYIHAQEGBASFNhiCMQmBECqCe4QOhDWBDSR7JxyBSUSBFUOBYIEAPoQOCgMRGoMVNoIugjc2ByYFAQIwMgQUHhEPMCAsHQg2AwUGBQEZAQEDCgIXBgkRKZB7CINIi3aJQJB3gQwKgx+RRIxTEoNeiyeGMZA8sx+BWToNAhWERAIEAgQFAg4BAQaBWwUtgVtwFYMkUBcCDolJhF8DDQmDTopeczgCBgEJAQEDCXyJT4E2AYEQAQE
IronPort-PHdr: A9a23:RtMOGBYStL4bsXjqZJ83f0v/LTAxhN3EVzX9orI4gq5Vf6Ll+Zn+b wTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pNVcFhMwakhZmDJuDDkv2f+Hjczc3G oJEWUM2t32+OFJeTcD5YVCaq3au7DkUTxP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP
IronPort-HdrOrdr: A9a23:/j7FNKsBSmvn2J0AAjaKkjNi7skCyoMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKdkrNhQ4tKOzOW+FdATbsSrLcKpgeBJ8SQzJ8n6U 4NSdkaNDS0NykHsS+Y2nj6Lz9D+qj8zEnAv463pB0BIXAIGsNdBkVCe3um+yZNNW977O8CZe KhD7181kOdkBosH6CGL0hAe9KGi8zAlZrgbxJDLQUg8hOygTSh76O/OwSE3z8FOgk/g4sKwC zgqUjU96+ju/a0xlv3zGnI9albn9Pn159qGNGMsM4IMT/h4zzYIbiJGofy+AzdktvfrmrCo+ O8+ivI+P4Ds085S1vF5icFHTOQiwrGpUWSk2NwykGT0PARDAhKe/apw7gpLycwLyEbzY5BOG Uh5RPEi3MfN2KyoA3to9fPTB1kjUyyvD4rlvMSlWVWVc8EZKZWtpF3xjIZLH4sJlOw1GkcKp glMCgc3ochTXqKK3TC+mV/yt2lWXo+Wh+AX0gZo8SQlzxbhmpwwUcUzNEW2i5ozuNzd7BUo+ Dfdqh4nrBHScEbKap7GecaWMOyTmjAWwjFPm6eKUnuUKsHJ3XOoZjq56hd3pDnRHXJ9up7pH 3laiIXiYcfQTObNSS+5uwDzvmWehTJYd3E8LAo23FWgMyPeIbW
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,289,1616457600"; d="scan'208";a="712799339"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2021 15:12:07 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 15LFC1CQ027673 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Jun 2021 15:12:07 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 10:12:05 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 21 Jun 2021 10:12:05 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 21 Jun 2021 10:12:05 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B8rusVp8+QxU2C+ExfafRBt5O+TMD8MeW/wPNw6cUlB1m3mUpsVZffeHkCCHm0VZdtFNQVWbZLIBIO80S/xzS0drzTxV2261dfI1ovohzsNRd3rr8EVM3uewBhDS+jxq3voIw6QxQziaK3hi5ZRBCAms8DFS4H/6hXIIliPAimkKc59S7+KncAzBdNpZVcfgdszlwmd3gjkl8g4lZuKRmDRayvBKBekPtZHPHpZAoxKCphkSYYGM+jrmEEzU1OU+bcym1FATA0fs3VGOmzhvweZtVQEu41egA6fY8CmfVxP7VZJSb2uOkwUFd8JsaJeAp3H0SNbn8c2m8WqkgqZ/jw==
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=URhdguD0g/EHnOTPEt+3BnN7HE5IX2zQ5JhlGQIOEts=; b=akJRaFzWcGb6n9DJ8FItRDQqekzBMl/c44eMYPZETbYrCKWfnhdfD+fi1I85SSEl3jQvuhAfSEQT2iTp60kpLqqwL+FSS30GKUsj/uXvEe/aJFSQhdG1ZnUU0Vh5GNdaqueaeDPpaYrmjLLxNXlMrVLIK4aTdYeXKv5bcQgg2d9ljLp1eowzTuS3OGWTMG2MAa5ZeQ5aWtbdKS5jzo8PQ1PS2l0AUtXfx1Qx2KkTNTCCsmCBeILCglXrs/h4IKbg1RQWfuTSZFGgrtNkDVBp2T4taUDKk0fVkqB1xoK58bc+W9aIYj318O0pSM3eQ6vjtBDUhjQ534qtBMvtYjY1Mw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=URhdguD0g/EHnOTPEt+3BnN7HE5IX2zQ5JhlGQIOEts=; b=fxPYsFrFLtTU4cA0RdkGzQxvjg9H9DdhlQLfb37tVQ7/haedBtcKCdCGXav6UsUpYNeKnO7+uXuUmZJsdT0tH+IuBeUhUticiJ5gmQqHAdOjg+uWpvBjRYC/GiAZsYMAdyGskhwHlV/6vzqkDSxufLfqVMBgKOla0Ja+UPXubAo=
Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5437.namprd11.prod.outlook.com (2603:10b6:5:398::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21; Mon, 21 Jun 2021 15:12:04 +0000
Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::e14c:8880:1101:bb0c%5]) with mapi id 15.20.4242.023; Mon, 21 Jun 2021 15:12:04 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-sztp-csr@ietf.org" <draft-ietf-netconf-sztp-csr@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Thread-Topic: AD review of draft-ietf-netconf-sztp-csr
Thread-Index: Addmei+76OsPA+grSaqUN2qOgkG4uAAMdT6AAAAewWA=
Date: Mon, 21 Jun 2021 15:12:04 +0000
Message-ID: <DM4PR11MB543824369BA6920C7FA67BDEB50A9@DM4PR11MB5438.namprd11.prod.outlook.com>
References: <DM4PR11MB543889219C08694C147C6DA4B50A9@DM4PR11MB5438.namprd11.prod.outlook.com> <0100017a2f082e6a-1197e3c8-f8be-4d59-ba1c-8d39029a31fc-000000@email.amazonses.com>
In-Reply-To: <0100017a2f082e6a-1197e3c8-f8be-4d59-ba1c-8d39029a31fc-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.12.233.180]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 362c3f03-191b-4b7b-fc80-08d934c6edad
x-ms-traffictypediagnostic: DM4PR11MB5437:
x-microsoft-antispam-prvs: <DM4PR11MB54372FAF896772AE69268118B50A9@DM4PR11MB5437.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NiIUDd+SOflpZWkBC9LCD3m270DRzn4mV9dtUhnZNQ27k0dwsQdFhGN4VF5dIt4rkK2b9+ceMuAvB3+E7fDYMWW3qRRngauyx/umKEIqy2UbmEgHHlt0CCSDaozqTWHwkFPykVPh1xHyNwEtv2HdCSIR6YC9Nn1GnMjvnVcvuVL2uK/lx+pBBllPuVrLdlOBEUHyxX18Ysk6c1kVow37jaGvvBBBUo1bID0FLGUHOis7tmqpYBjO8Ul59CD/IyYHZ8GqnwfQpujtJAmpZIADZ7rIaRNzpeNYILZdTiAWnpozGzxdDruVLRTxYHTLC6wNnrtB83RzWJH/T8x9vMBRIFYlXnCBc1RAxRmsJcpPCZdjTUrwTFNTXVmFphCoRjppOn2h2aogNNUSC2jmNYnepP5kq21Z06eG0SnZozhydYLdVOTvfgNzYU5/i0rkCtwwC3NlXmcJnoNoS3qCXfGWAceiXdFlEpOQQcY1DuUTnOnCbj/VZWwN7SQ9odu3hVshqwpYFqjtW0JLvQt9T/v5dA8rxSb2MDDwjxy5xKwUQYR0z0KAiNpkzgv0qiaXNVNRdQLtGjfN5qGvyMciEfTElMY6KNDOEiFaeLxgq16R124=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(136003)(396003)(39860400002)(366004)(86362001)(26005)(7696005)(53546011)(33656002)(186003)(6506007)(4326008)(478600001)(38100700002)(8676002)(5660300002)(71200400001)(66556008)(54906003)(83380400001)(316002)(66476007)(76116006)(55016002)(122000001)(64756008)(9686003)(8936002)(66446008)(2906002)(66946007)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: lcE1MjwrJ1J3UVF/8ZsjI4LP498cijqy/KgccD2MLmc6SkM6Viol4mi805DYWnzDXbS7QUTrfUo0oEIOPtpu4nS2MDKPk3si7C+sqnPCCPj1Yx/Lognw5MlX85flg/K0ge7bFLNAoAp48lYw+ARKn8Ym52VA2KzS7cNkwZ1N22Expu6lESLRxM/uu1d03a88jkAbzheu9xBaYvxL0tN8GVK3W7hbHOBMqDqQH2s8oqNwbztj9rG+QEpoqaDjMROPUzCBxjUr4M5nzwIXuKImMAk06CJKA9MWBRlHnScrkRViBmJbixmc4rwo2Y1YZECcLsmL2KsuhhYwsTJWeHOVPYhvI8ZTM1oUWCUSZ1nN0Mvjjjox5z9JAkILK4SmievDbfqmv6XTe2NShroTMswkV7KGMtfz4hzEKwFiBe/s26mW5ppB8Uasb5kRBBYmpiI8hETs+/KwtDN0Qtx/Li19tRA9RtGZfNT8MK8wgzOcXIPDnrADmyXnO2qFFIhZaW3+wbF/Aa+WS9Vcxri6eL6VnWoB3oicjH7a5XNtpekV29euZQ07E+kdH/BXb+TgabBmwjbHbro1SCoD/gs7AIm+N8yKQvUi308gwJKlrQeZ2UWMv7whZmxkhXJhKVZcwk5ZGClh8mOnwilBLLr9jtgdWyEKNH2HnjMbigOu2Rl4nfvw6m6E+vdieEQlGoq8FCYxTNBSUngskW1zd05+JfeDruo61CC80tcL9qn/E07NzdszhFRnBh4siGQFj2g3MGV07dqpbD3OFcoqCzmFnEMmHcHNylQyf+V/FTV/oGV1mCYDxRAlY6amNpfIcDIOmexPAulbPbiiFSMZjLOFQFMziTmGGOssCDQvzhkzaT6Oi5Pqae8xdiDEJQOqeGI8cCM59ZLDXH2g7ixXw3bRP/S2LlsgMp3ehfCkGjQZrZR4ufYcuWYZUu3rGi0GdtwaBhQ96u34hLQiNS8xeSNTuFTco5sIE6hrxiN4ab4dQ2F8K2UjEE1P4/HKfl20An8WivicP7VlB6Jt5pKhTNWJEDGjpMh5SKXsRgF7ZavIVvkOvl9Vv4Yt3tykFkgh3hw+4NMqvDSwTpNRBWE/O6t+N2XU/Q7Cm/66sU5wOkrUjz7vanqYTUVxqhrNFUaNpmMsj67mPXjqsoWsOeypXzC5mQoe3dIuA4bY0mCBtR1hi0gD8ljoQ6uXctOjv4upuJ8FZNHa3TLlAwPjSKK6dMf8cQUjcmsLz2hm4+XcIo+1f0dOWsJHtm69e8EWcoLY1H4OULtCEUp7kGWs9VOSxh8HEnga19h0L3xnsFpr5LpZ67lYH9WmRstfWH+5vUmJOVhKNVcV
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 362c3f03-191b-4b7b-fc80-08d934c6edad
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2021 15:12:04.3854 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cJ+e91vo//prK/c7lun9YOhIqzt0XUl1iVA+W+GDR4mTFq/y+F7qFXzs5SFFtOd5wYaC5oH9Q5TaEEOqc1tUXQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5437
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: alln-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/4P0FBNDP7HMaPf_24VFgnGBeXG0>
Subject: Re: [netconf] AD review of draft-ietf-netconf-sztp-csr
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: Mon, 21 Jun 2021 15:12:14 -0000

Hi Kent,

Thanks.

Please see inline ...

> -----Original Message-----
> From: Kent Watsen <kent+ietf@watsen.net>
> Sent: 21 June 2021 15:45
> To: Rob Wilton (rwilton) <rwilton@cisco.com>
> Cc: netconf@ietf.org; draft-ietf-netconf-sztp-csr@ietf.org; netconf-
> chairs@ietf.org
> Subject: Re: AD review of draft-ietf-netconf-sztp-csr
> 
> Hi Rob,
> 
> Thank you for your review!
> 
> 
> > AD Review of draft-ietf-netconf-sztp-csr-03
> >
> > Disclaimer, I am not a security expert and the security specific aspects
> > (e.g., the precise details of how the CSRs are encoded) is beyond my
> knowledge.
> > Hopefully this will be sufficiently checked by SEC DIR reviews and SEC AD,
> > whilst also acknowledging the expertise of the authors!
> 
> Ack.
> 
> 
> > My main questions really relate to REST semantics.
> >
> > 1. It is always the case that the SZTP-client must do the handshake with
> > the server (i.e, populating the csr-support container, then getting a 400
> error back,
> > before making the actual bootstrap request), or is it acceptable for the
> SZTP-client
> > to guess on acceptable parameters, and send a single request?  Obviously,
> this cannot
> > work in all cases, but I want to check whether it is allowed (or explicitly
> disallowed)
> > in any cases.
> 
> A handshake is not strictly always required, as:
> 
> 1) it’s possible the device could automatically generate a CSR using the same
> certificate information as present in its IDevID certificate.  This would allow
> the signature on the resulting LDevID to be from the deployment’s CA
> infrastructure, which has value in and of itself, but the LDevID would not
> contain any new/different/interesting fields, and hence might have limited
> appeal.
> 
> 2) it’s possible that the device could automatically generate unique keys and
> associated p10, cmc, cmp structures (i.e., every permutation of key-algorithm
> and request-structure the device supports), but this would be expensive on
> the device, especially without knowledge if the deployment’s infrastructure
> even cares to set an LDevID on the device.
> 
> For these reasons the authors felt it best to introduce the dialog presented in
> the draft.
> 

Okay, I'm wondering whether a sentence to that effect would be helpful, since when I read the draft, my impression was that a handshake was always expected, but perhaps I'm missing something?


> 
> 
> > 2. Section 2.2:
> >   Assuming the SZTP-server wishes to prompt the SZTP-client to provide
> >   a CSR, then it would respond with an HTTP 400 (Bad Request) error
> >   code:
> >
> > I wonder whether returning a 400 "Bad Request" error is really the best
> return code, i.e.,
> > it wasn't clear to me whether this requesting the capabiltiies is really an
> error.
> > Did you consider potentially using other return codes?  Possibly:
> >  300 Multiple Choices,
> >  403 Fobidden,
> >  406 Not Acceptable
> 
> I did before look at all the 4xx codes.  I was initially drawn to 412
> Precondition Failed, but noted that it is specific to HTTP request header
> fields.   As for the others you mention, the semantics of 403 Forbidden is that
> the request should not be repeated, which isn’t out case, and 406 Not
> Acceptable regards the use of the HTTP “Accept” headers, which aren't in
> play here either.  That said, 300 Multiple Choices does appear to be a better
> if not perfect option, so I made that change in my local copy.
> 
Ack.


> 
> 
> > 3. Does it make sense to recommend a default certificate-request-format
> that clients should
> > support, or does it make sense to not prioritize any particular certificate
> format, effectively
> > requiring that a generic server needs to support them all?
> 
> No default format is possible, as it’s completely dependent on what CA
> infrastructure the particular deployment has.
> 
> The impact to generic servers is minimal as, for the most part, they simply
> pass the structure to the deployment’s CA and subsequently relay the
> response structure to the device.  Only if the SZTP-server wishes to inspect
> that contents would it then need to step up to understanding all the formats.
> 
Ack.

> 
> > 4. References.  RFC 3688 probably should be normative for the XML
> registry, noting that
> > RFC 6020 is normatively referenced.
> 
> Really?  I tend to disagree as I thought the litmus test for if something were
> normative was if it had to be understood in order to implement the RFC.

I guess the logic here is that you need to understand RFC 6020 to understand the registry that is having entries added (given that RFC 7950 doesn't define the registry).

But, as per below, I'll check with the IESG on this one.

> 
> You raise an interesting point about RFC 6020 being Normative, as I see that
> it is NOT normative in at least one of my other drafts.  I think that it is a
> reasonable position that, if the RFC 6020 reference is only present in the
> IANA Considerations section, then it is INFORMATIVE as far as the draft as a
> whole goes.  Thoughts?

Let me check with the IESG and get back to you on this one.  Although, perhaps worth noting that both these references are normative in RFC 8343 (and they are only referenced from the IANA registry entries).


> 
> 
> 
> > Nits:
> >
> > 5.
> > In the example data, would it helpful to add a sentence to explain
> >               "base64encodedvalue1=",
> >               "base64encodedvalue2=",
> >               "base64encodedvalue3="
> >
> > Actually, given this convention is used in various places, there is a choice as
> to whether
> > to add a sentence to each example, or perhaps in the introduction.
> 
> Adding a sentence to each example would be ideal, but a ton of work,
> especially considering my needing to propagate it to the suite of client-server
> drafts as well.
> 
> Adding something like the following to the Introduction section wouldn’t be
> too much work:
> 
> 1.3.  Conventions
> 
>    Various examples used in this document use a placeholder
>    value for binary data that has been base64 encoded (e.g.,
>    "base64encodeddata==“).  This placeholder value is used
>     as real base64 encoded structures are often many lines
>     long and hence distracting to the example being presented.
> 
> Thoughts?

Looks good.


> 
> 
> > 6.
> > 3.1.3.  Replay Attack Protection
> >
> >   This RFC enables an SZTP-client to announce an ability to generate
> >   new key to use for its CSR.
> >
> > "a new key"
> 
> Fixed
> 
> 
> > 7. In Security Considerations:
> >   Generating a new key each time enables the random bytes used to
> >   create the key to serve the dual-purpose of also acting like a
> >   "nonce" used in other mechanisms to detect replay attacks.
> >
> > I wasn't clear to me what the two purposes are here.  One is acting like
> > a "nonce", but what is the other purpose?
> 
> :laugh:  The original first purpose is, of course, to generate a new key at all,
> as opposed to each time.   Please provide suggested text if you still think it
> can be improved.

When you put it that way, it is kind of obvious ;-)

You can either leave it as is, or perhaps a small tweak (moving also) might make it clearer:

   Generating a new key each time enables the random bytes used to
   create the key to also serve the dual-purpose of acting like a
   "nonce" used in other mechanisms to detect replay attacks.


> 
> 
> 
> > 8.
> >   In the case the SZTP-client must choose between the asymmetric key
> >   option versus a shared secret for origin authentication, it is
> >   RECOMMENDED that the SZTP-client choose using the asymmetric key
> >   option.
> >
> > "In the case the" => "In the case that the ...
> 
> Fixed.
> 
> 
> > Terminology:
> > Should you add LDevID or IDevID
> 
> Maybe, but note that this draft (as with RFC 8572) carefully refers to “identity
> certificates”, of which IEEE 802.1AR DevIDs are mere examples of such, but
> by no means the only possibility.   It’s unclear if promoting such an ancillary
> reference to a top-level term is appropriate.  Currently, as I’m sure you’re
> aware, the draft has a reference (i.e., an <xref>) where these values are
> used…admitted, likely more times than necessary, such that I wouldn’t be
> surprised if the copyeditor were to eliminate all but the first references.
> Thoughts? Please advise.

Okay.  I'm happy for you to leave this as is, this is pretty minor.


> 
> 
> > Potential spelling warnings:
> > descendent
> 
> Fixed.
> 
> 
> > Grammar Warnings (from tool):
> > Section: 2.3, draft text:
> > This module augments an RPC defined in [RFC8572], uses a data type
> defined in [I-D.ietf-netconf-crypto-types], has an normative references to
> [RFC2986] and [ITU.
> > Warning:  The plural noun "references" cannot be used with the article
> "an". Did you mean an normative reference or normative references?
> > Suggested change:  "an normative reference"
> 
> Fixed.
> 
> 
> > Section: 3.1.4, draft text:
> > Consistent with the recommendation presented in Section 9.6 of
> [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input
> parameter to an untrusted SZTP-server.
> > Warning:  The modal verb 'SHOULD' requires the verb's base form.
> > Suggested change:  "pass"
> 
> Fixed.
> 
> 
> > Section: 3.1.5, draft text:
> > All of the certificate request formats defined in this document (e.g., CMC,
> CMP, etc.), not including a raw PKCS#10, support origin authentication.
> > Warning:  Consider using all the.
> > Suggested change:  "All the"
> 
> Fixed…and I learned something new :)

I think that "All of the" is also technically valid, but less common.  Perhaps this warning is a bit picky ...

> 
> 
> > Section: 3.1.5, draft text:
> > Typically only one possible origin authentication mechanism can possibly
> be used but, in the case that the SZTP-client authenticates itself using both
> TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed
> by Section 5.3 of [RFC8572], then the SZTP-client may need to choose
> between the two options.
> > Warning:  Did you forget a comma after a conjunctive/linking adverb?
> > Suggested change:  "Typically,"
> 
> Fixed.
> 
> 
> > Thanks,
> > Rob
> 
> K.

Thanks,
Rob

>