Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 15 January 2019 23:31 UTC

Return-Path: <kaduk@mit.edu>
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 0AEE212D4F2; Tue, 15 Jan 2019 15:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu
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 OKjcwcyNdF6K; Tue, 15 Jan 2019 15:31:33 -0800 (PST)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800122.outbound.protection.outlook.com [40.107.80.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824281292F1; Tue, 15 Jan 2019 15:31:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QMpryjLgEsyu6qPVsYXw967evkahaH4koJu9LCuJZok=; b=VpXH96uKaNHotfq8d5VbxVLOout8mbNeIPnZxEyR0weMJNSAMQYxNE8zDmORJvMj29KvQOfMGnCQK0TNZmyJDuNuPLxDODyTpBz6n/XVkwmSi6EHpavFIR0wNUMoNhGLXnCPB8afp+tU2fRDm4Ro0mO7pcKbk+RtYGwxK8YLgLE=
Received: from DM5PR0101CA0004.prod.exchangelabs.com (2603:10b6:4:28::17) by BN6PR0101MB2977.prod.exchangelabs.com (2603:10b6:405:2d::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1516.18; Tue, 15 Jan 2019 23:31:32 +0000
Received: from BY2NAM03FT056.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::205) by DM5PR0101CA0004.outlook.office365.com (2603:10b6:4:28::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1516.18 via Frontend Transport; Tue, 15 Jan 2019 23:31:31 +0000
Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT056.mail.protection.outlook.com (10.152.85.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Tue, 15 Jan 2019 23:31:31 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0FNVQWL006218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Jan 2019 18:31:28 -0500
Date: Tue, 15 Jan 2019 17:31:26 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Kent Watsen <kwatsen@juniper.net>
CC: Adam Roach <adam@nostrum.com>, Dave Crocker <dcrocker@bbiw.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Message-ID: <20190115233125.GB91727@kduck.mit.edu>
References: <42cddba1-9f59-f19f-176f-197f0c0c0c96@bbiw.net> <32cfe06c-8204-a63a-263d-cb5b30a7a2fc@nostrum.com> <20190110183444.GN28515@kduck.mit.edu> <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net> <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com> <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net> <20190112005406.GU28515@kduck.mit.edu> <A1F059FB-5229-45B9-9EBB-CF60B78FF454@juniper.net> <20190114221155.GL28515@kduck.mit.edu> <F68D5933-715C-4475-92B2-22DD06B5CA20@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F68D5933-715C-4475-92B2-22DD06B5CA20@juniper.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(376002)(136003)(2980300002)(189003)(199004)(40224003)(336012)(7696005)(426003)(86362001)(229853002)(186003)(76176011)(36906005)(8936002)(54906003)(58126008)(316002)(16586007)(8676002)(75432002)(786003)(104016004)(26005)(6916009)(5660300001)(246002)(478600001)(1076003)(26826003)(33656002)(106002)(55016002)(305945005)(14444005)(486006)(93886005)(23726003)(53416004)(1941001)(4326008)(97756001)(106466001)(46406003)(2906002)(356004)(88552002)(126002)(50466002)(47776003)(956004)(476003)(11346002)(6246003)(446003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR0101MB2977; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT056; 1:yG9UD9rLWcfG2tL9smM7X2Xa1o/JuZBviaypFOroGiTzX0sD3eywOlLL81Ea8xThgVAb79kYT55YIdXcV6Gu8K8V3pvqkj+rs4fcYw1wxmjwaTVa67H6fEfAi3wEHY7m
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 82e83cf3-86c3-46ed-d680-08d67b419493
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BN6PR0101MB2977;
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2977; 3:ZN9FmorrEvexpypeh3A3umktwyOo/TkiC5+xve6Nxq2YnwYEyFe2qiRhxOaoE/+EalSW6VslsO4KDURmLLTe3nPJBcexxMqgoyKLogZJ2kCdPtcNcKbtWz8KypI5i1a8hZAU63Iqh7/iAY7Ht4o8QX6zqavvrULC5Q7334/tFw/CvkNCx+mXU1FDp+8ekdphr6t0NVWy24JMBTbAluXEvTxJuK/ns0O6Ve60oPvvXd11szcoq3zyfcUvz2k7mYogRnlq3w59sDSzmyYhoaeyAzOKkMG28u/7euuNFaE9VdEGlFZdCZ7ozu4I+4BUkNFVy39M+0Z45VXKKAWHTYghBKNBQ5WLUdi8glWrZ6zm1itu+W0jsKmU/dhp3G5GA2+p; 25:IGwQe0OJaM+fRFH2s6OFZcNMdIUuYVu7FjBMOLNl/bBn+2wh54636ZB0d/vxNZjMQWXMRF0/lQ6Fo74rICeMCLqW+/t/u+JfCFO2/X/qh03dn537OGKr1Td5ElTha+9PTvzFcTbryzLIqFx1qUb5rTh4ju6iCaXBn66l7MnJYTUcExxVd+GUUwQNrYjtBg7NW+0/Efq/zgrEODjumP2QvKADzVvp2+xCHNrMm30xvAKq+EULQrvNRZh2kxrudcgyJ8LrAtjT1EYWkG1Xo/+X37LzE1JY+njiDGjdrfWilOO9is5abmeAqcSfbWhGbhDewLDNn65+kB9JlEnyrVf/Nw==
X-MS-TrafficTypeDiagnostic: BN6PR0101MB2977:
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2977; 31:EYWZ6i6UwOInorbOkGAhDlLjl5nCU3MlIzZ4sPIw4DeVj8ERyFGh2Ip+FY3EkaYZl0ZbS0L6IekHJ4H+pJTmlWPGAOHSlfh5/DOBjAvfCwsZoe/4W79URb6zQcQXlGgCGVUZdbMU2FbCn6XI/rO7Ju9F2th6QvbAcUgLOPKHkch/z4xBqqDFxEQGoaHvOEbN3OYbeF0p7MuRnH/+ovFbLo4bfqWqnKdMTmVdumfUIL4=; 20:G3JSEu+0O/3iVPBf6amCGehdzCc5A/xt0/RuZmVJa4I2WuzIQ7dz5jedtryeSO/RYXJG5+M17/anRss9tt64h1Tc3oDPyjhVm7BdLgisUo8b/O6JtGrXN0+911GAiAwS/tr2oA7lBHhKM1jxaOQDJAZUh8kaC6sOv9BP6ZDfAHywKa2rp0qN6GR+IADKIkrkOvu48D4Z4KXNaHr144KcsFiScytlYvBboKHhIGMRy7JkqiqiX0OiD7gwQDEiFbZVxC7nyP6ndAlTI9Npv1iFbvnkG3xc231xr1FaZJqVvOWHoy51xZyNDPU+ocQHRkDan8An/JDqnRm/pNhhqnA5K3923iFxW9yNwa4f+eYbpl6ZnSBMunoWU1rpAG813sUW0gh5eE7zACOTwjg7k77zmgyNdJ0I+oXprrnnrcdbO8JHEgJH+u4xqAIZoWwMkkUABxhKKgK/MnaRyTA/GJAyxZHDm3mTcGAIK73fnjF3ycSc1CtXtceycYKBwf4D3lnFxm2DwDWwbXli7pk+6jZXKIH+x0ZWLJhKqqFltk4DtXThNoTRgACzljePVYAS8KoETlboFLJgtZ1SDg1YZUY64V59tnr6X66KdTspUkSQY/0=
X-Microsoft-Antispam-PRVS: <BN6PR0101MB29772753DCCDBDBEA1425800A0810@BN6PR0101MB2977.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2977; 4:SF6YlqmUpzVYSYm/35cVK2co3rVqOjx8QRCiUwYJfncTbbMvHnre2k6gjL1Abp1e2rm3gWB+zD41KJcup93w6bi5IWiGRDzQiPY+f70303aLoe2sC4ScxsbwcjNCgd0v2ZF1gGWPh3gKFkKeGcrOoOcqgna+ZPQFscRu/Gt2DAH4WEL/o4qB+ZjlARSFWRFoHRmxges1kpyYLjPMppABIiPn9/SfG6T/5h3yFqITJiOneDNeIHZ11DdkVwJmJFQvBP3fH9x14jufMoqLMMH08bivXCKgeLtWhccYW7ZITrw2WsKG6AhtB3Lrmnvr9PnB
X-Forefront-PRVS: 0918748D70
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2977; 23:2cC+JYpoS8f/liPPpcZJMwGp+TVSBk+FHfegMUup0G2vxp4HhWWJ5XPZoiM0Hi4NkrIICUe91z1jUPaqDVm3o+8XZMCCwqBphmnuuKK0blJzPLfD2j5SXQfafIpTpjVojYo1BnmJK017Ydyol3sG1asOtQcOafD3yABuETj/2LfBui7ytBifeqd+GjuHvPDrcrUoYxZ2rWeMEdLVGBRLNXP70HqIi9MBG5jyH90vf7GwnBKzy59STcFtpIb6DI8khZW3AZr5a54ba4JtaXnWwHzNflCaV2g/GRWfomc8rTTjJ/SgPX5jGVvmgcEYpgXvxQPU0Q070Ffkv2TRwGu7MqhgM49LJqW+I9fwy7vTbgW/BIa87GZH4VYIeZT6Is7gQIVZ5PaFCH5LEU5si25Q5N9w1H7zDK/oZT0HyOmgR8xnagw2+8jaJ9xKM+W2RZUVDgLFdHUoE9yV+Sg8xj6wcack312risGNT2qTwlO+HYEG7I6MXodjM3NdM78qROCFueBZau7sbNe/+mx0hZ+BGsSTyKIhimEvm59xWp3CNK9Zuv4zqUUAxm2vwkfO70vigi6hxcuK5gp6x2zZ8/lAGjGAcjVswYRKWJ2VaH2yjTJ3sLf+zXzvANTAb9dSb5ro/9Vyzy/BnwGSlgqU8aOH9wBTziQt3xvNF44OIUFN3m6zVI+g9YT9np8sAmaTcWakORGwIChFC0ABG8xDn797RrcG2j3Anz+rWI/h2uIxYwvwT89sFyjciDpCzgIHqnaggA5xJsZStyBjzTvRibTLc1S9bjFeKLtZoxuEIuPP7kkH4aMiheYM3LO84I5XPPBS5arj+0WobTFN57yj5wIShGun/elavrnew4DOTz7tevs1krxpmxhCCzlNSHZyYBm0mB2dxBMxnVWVi+fwBJGO2YKGycOYWMlrfTmnijgBD0gq77/lz0c0mHH92bOvjlwd41cZ0aRsCLqTF1Qsml2JM3xFoU/Gh21WCJWARWVvKHQ78u4Pz5EMcQeNc2JRfhmYHnTcLWkZOnxjrMYOiK0SXiZPWe4mDmVF2CbI7sUbpvI3BPip9xahi3JFjaaY2D3ERwcjn2a0djHislJyEL4edIqj39LmuqFWFhcPhfEpMmYkY72iZZF3dcH/StxPag5NK08Fnl5rGD96KA/A7aUIJhQLXBUXzwQc6MelgeguMoq342NMLsOVR12i8527gptdSipoInxVNnSPoouhi07o1Tvrzc5iw8Y9XcRBgV8Ixa164D4hD7RTMIKYDPpTFb1Rcw/Ho1UdyaaMIqFWXkMEWg==
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: WS+BxoOovyjttQahKfuDBiKrRSv3LfB/cRsyuH52JBcmaEvK240XmOC1ZGIh74O4w+nupEEvDg2BGvn1gMwsLQMVrvdHY05QmgvlDbT9ubsa1oMmL73s+WNHuRWhg9UvUcH3Vt/GsccurFt+pkxy16hnr4YSspNwMO3wAT7yMSNSRIBoPb1Ityf8bimTZdYVEW0Zor4hAP7gka4Y5dVUOaKR44YG4bnDxOxYn/aeHVBRhzXDVSqunUtEUpAObH+PXWJ669lrbRejIX0YkwOrMEv9bhlO3gDCJ2+OJEyeAyOlDS0vcyNzYKF1DvA5y4k6Or8UHBOXxlOAxPhAej6ACwhcvJ2tT+NMnPu/KJ4YwEzZExT2rrJfoGDpegCJPhsdzytp88bBcJY6zd4526fgdbHXbHUyWb37giXxRfMajeM=
X-Microsoft-Exchange-Diagnostics: 1; BN6PR0101MB2977; 6:okOUAWJ5mnWFPsoYVDCryzY4XbeK/Zg9ItFQCe5M14x9R+YSrQ8qR6A66z7JRApkcH9UwkGp8omNjL2iELSK2JOrSz4YRUkVUpBBcA44+FwknOHAsnOmScMO9liHLjWb7UwndZ2AbI76aub88Ad8HBN6fAhEQEZJKK/UH/BnZ8L5hGb8Onblr2OGX99rHjj3ZjAmUQ7JxDxvt7uPtZKvVSWbisdW6oqkf7avM8UsgBoDJ8ZE1B6v+w6DM68p+tU/0Tup6I0Iu4kLaRpnkr4ve4SSrg2PSI7lv+5JT7INWmX/fo12PYm+SgDIrP4U1WuKll2DMYUsdZg4pkPmXM/rsEW4uEk+YavfdMaX0X4GOlRB9sx8OGgccD+/qmaD7gUNnoExh2D08sPX6NsMEwn5aqG+RGK/JuaVpFT8S2Ow/irbCdG6EZJ6kLA8lM1JTk6DJ7O3QwuoGEiDbaOD39HMVg==; 5:1cge2qFzKuF+OYGgqotc/vMgcDJ5pzJkTMhHPe1IIvDlI4Og+1Ezkhk/pEDwDSLB52Q+I8EtqGwn6Xh1FvhjRiuUGqxnbV9lWVdtUy0EuMIwGxIO8UaEODqtK4PIasv1bNiR4xGRv1kPrd1ZFuTImIKUP6S0uwyf8eq5NUk2gpjGjSz5trxTzm5YlwUWaQiUrWxox4xxZ1z2FJemlufQvA==; 7:JeBa+c0tth74hcQEhNZxGeqsqh3bvQMtrVDaXX1B3fk/wt3XPeUScskMrpbpysL1LyWux9v3ypHVTzENfgYnxX9CYXyxCqKuEysYeiZyKP/0tDb2uby6Ra4Uzqypjdfyu6+idSpVBcHEtyg8ztZzDw==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2019 23:31:31.1248 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 82e83cf3-86c3-46ed-d680-08d67b419493
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR0101MB2977
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/6YoEA6FvvR2igG3wBAwJ3qpBPOg>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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: Tue, 15 Jan 2019 23:31:36 -0000

On Tue, Jan 15, 2019 at 10:43:59PM +0000, Kent Watsen wrote:
> Hi Benjamin,
> 
> 
> >> Yes, that is the correct URL.  I've fixed it in my local copy.  
> >> The 802.1AR spec is behind a paywall, but it says this about the serial number:
> >> 
> >>   An IDevID certificate subject field be non-null and should
> >>   include a   unique device serial number encoded as the 
> >>   serialNumber attribute(RFC 5280 X520SerialNumber).
> >> 
> >> From RFC 5280:
> >> 
> >>    X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
> >> 
> >>    ub-serial-number INTEGER ::= 64
> >> 
> >>    The character string type PrintableString supports a very basic Latin
> >>    character set: the lowercase letters 'a' through 'z', uppercase
> >>    letters 'A' through 'Z', the digits '0' through '9', eleven special
> >>    characters ' = ( ) + , - . / : ? and space.
> >> 
> >> Any comments/concerns about this?
> >
> > Sigh.  There could be some excitement here (but might not be), but I think
> > I'm going to have to defer to some people with more DNS (and X.500)
> > expertise.  There's several potential (but not certain) issues here,
> > including at least:
> >
> > (1) ub-serial-number is 64, and the maximum length of a DNS label is 64
> > octets, so we have no room for escaping or encoding at the margins.
> >
> > (2) RFC 1034 suggests that DNS domain name comparisons should be performed
> > in a case-insensitive manner (for alphabetic ASCII a-z/A-Z), but that
> > labels themselves can contain arbitrary octets.  There is some placation
> > here in that X.520 appears to define the Serial Number attribute should use
> > a caseIgnoreMatch equality matching rule, so maybe this is a non-issue.
> >
> > (3) Those extra characters (other than '-') are not allowed in DNS host
> > names.  AIUI, that technically shouldn't be a problem for this usage, but
> > I'm not 100% confident, and maybe some implementations are wrong.
> >
> > (4) Using '.' in a label is pretty rare and require escaping for textual
> > presentation (but this is not inherently a fatal flaw and would not hit the
> > 64-character limit on label length).
> >
> > But on the whole, the question I want to ask myself here is along the lines
> > of "how likely is there to be implementation incompatibility in this
> > space?".  If serial numbers in practice are not using the full flexibility,
> > this could still be a non-issue.
> 
> Be aware that the draft must, in general, say something about the serial
> number for each source of bootstrapping information (and note that the
> draft leaves open the possibility that more "sources" may be defined in
> the future):
> 
>   Removable Storage:
>     - okay, well, the draft punts on providing an actual file-naming
>       convention but, in theory, there could be a directory per 
>       serial-number.  E.g., /<serial-number>/<artifact-file>.
> 
>   DNS:
>     - TXT in <serial-number>._sztp.local.   (multicast)
>     - TXT in <serial-number>._sztp.<domain>.  (unicast)
> 
>   DHCP:
>     - the draft punts here as well. DHCP is the only source of
>       bootstrapping information defined by the document that
>       doesn't support device-specific response (bootp payloads
>       are *way* too small!)
> 
>   SZTP Bootstrap Server:
>     - device MUST identify/authenticate itself using its serial-number.
>     - device SHOULD use a client-certificate (DevID RECOMMENDED)
>     - device MAY use an HTTP authentication scheme but, if it does so,
>       it MUST identify itself using its serial-number.
> 
> Lastly, for any source, if "signed data" is returned, the ownership
> voucher [RFC 8366] defines a "serial-number" leaf that MUST be
> populated with the serial number value.
> 
> In general, it is felt that, if a device vendor's serial-numbers
> contain characters that are not supported by some protocol or format,
> then that is their problem to solve.  That said, most protocol/formats
> will define some escaping mechanism and, if not, the vendor can create
> some mapping.
> 
> As for serial-number lengths exceeding some limit, then it may mean
> that the device vendor either can't use that bootstrapping strategy,
> or, again, they come up with a mapping of some sort (e.g., a hash).
> But I doubt serial numbers ever get so long, as they are many times
> typed or spoken, and users would revolt if they were too long ;)
> 
> My hope is that we can ignore this concern altogether, or maybe just
> have a Security Considerations section that essentially captures the
> above.  Thoughts?

I'm inclined to believe that we can just ignore this concern for now, based
on the above discussion and having thought about the issues a bit more.

(I also see that Ignas has already pushed the "approve" button, so the
publication process is underway.)

Thanks again for all your work getting this one over the finish line.

-Benjamin