[Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR
Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 15 January 2025 11:56 UTC
Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A69C169404 for <anima@ietfa.amsl.com>; Wed, 15 Jan 2025 03:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v_0XYAUd_Ti for <anima@ietfa.amsl.com>; Wed, 15 Jan 2025 03:56:40 -0800 (PST)
Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2131.outbound.protection.outlook.com [40.107.249.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2564C15108F for <anima@ietf.org>; Wed, 15 Jan 2025 03:56:38 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=E+NptXosL0SsbYVUffMZOi7r9arBHxscZFCx4gpjLuMsFhzOE8txrzz1NBwGXCFfHJH1eqJbhZBWZzfHbT4ad1dJJnL0U+wCZ3s0Bt7MSW2xBU2WKy2g7cnPy4nQ29RjiuSIkcbw5L+5nhSukoIVM2Z6mpIjeuaiNUUbWhB+dlk3X+qD6wi0thikBU9093XEYJzS/Xz7yPcM6rrlJ6N9Wzl10XWEJtx42ZentWjz8Dmf0Gljm0gbd3XPlngnG9gxaKEj3F10Byiy45WncGTyr4Z5cLhh4ISzpl8D8GHpNlIg8ur3/HYlj2MJ7LR05b9dkbQmQWhXY8QeVbhlIb+MQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=C6PnS2ev4bA/3SbRTJ5GAkHhTfp4d1lXgy+ecVassOE=; b=aMP42c7ewLsZ46Wf95SO2pFjvdumKUI/HijyW7ydBnQyJtBE8JPex0nX97r6cBB1B8Ti2EaKufXKLM9nvDemtJVz9agteqhqiqm33S4XM6INNaNYH3FhiZjRak3rPjmX5mVSu1VOvv1otak0o9BbL4hB4VR2TvvaWCRKj3DMTN2y7FN/Al5kM9JSLx4vhIojsrARZlpjeWCXFLw5eL8xCsCzb7OpCN88IZ2jIbR+dNW/yu6TyiKZwetkhR6av1DUHiYeyKhebErOJz0hS4itjXbfuAzo7SxSFfnRma6Ks6TuMUMBg6ZeOQLbSaZwFB4h5wfJ9gu9jVY25OroiZCGRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C6PnS2ev4bA/3SbRTJ5GAkHhTfp4d1lXgy+ecVassOE=; b=csRLLsxlmGEVm0p1qaKKAm8AxQtiFSfQTy+UWbDsOYifaa8dnrW6VznHGPQ3SIuzfuC5oPmcEnpBxNg6snrUHsREOGSd32w0EZApCkgeoWqKy2py3+Ufbk0P7OgxYy1NARGsRsJoAHcekHZ9Mh6Ql49Bx5tvNzSw8KOrzy9/C1w=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by VI0P190MB2186.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:256::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8356.13; Wed, 15 Jan 2025 11:56:34 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::5abd:5aa2:7005:acc6]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::5abd:5aa2:7005:acc6%4]) with mapi id 15.20.8335.017; Wed, 15 Jan 2025 11:56:34 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "Fries, Steffen" <steffen.fries@siemens.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>, "Werner, Thomas" <thomas-werner@siemens.com>
Thread-Topic: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR
Thread-Index: Adtmp8DGaGc33rQTQaSJ4oCTIvlRkgAFzH4AAAWoN4AAE5ifYAADrQLAAAMI3YAAASXscA==
Date: Wed, 15 Jan 2025 11:56:34 +0000
Message-ID: <DU0P190MB1978EC89874D124F12862885FD192@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <DU0P190MB197881C7B003306108D9AE43FD182@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <10111.1736884824@obiwan.sandelman.ca> <DU0P190MB197838F0171066F9C3CEB801FD182@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <AS8PR10MB633739382769A2B9DA1B968EF3192@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM> <DU0P190MB1978407253DFB037019CC04BFD192@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM> <AS8PR10MB6337A3D555DE303859ACFF67F3192@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AS8PR10MB6337A3D555DE303859ACFF67F3192@AS8PR10MB6337.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=8916ab4a-f09d-4efa-9ab9-6522483ca3f0;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2025-01-15T08:03:28Z;MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0P190MB1978:EE_|VI0P190MB2186:EE_
x-ms-office365-filtering-correlation-id: 7c6538c6-9f1c-4ad1-4ecd-08dd355ba88d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|10070799003|7055299006|38070700018;
x-microsoft-antispam-message-info: gLI3CUfO15a/INvnnWtbvljO4TJ2S4OIt7mi1njsBUiDAwoDrfm/lmLX20DDQRgMf+6V0PgtHcRnkCkOB2K1vHipY3kTzu75cDlK/557WxQBoBXQs8ZVe8UFOQksHJJG9+SEnBvVhFsKWsaZIVfFIqDWJAaSNGZO2sbxVQBcmv1rCiZ1A87EAPJkSOTjwGuI+tG11PmsUkZztqiasPaegvam3oTBCsZRHqLejIWDxFkbBoj25PcT2NOK2fyhY+M1WX2IAqb1kjE917JGxE3PbrTTRSBOlvjeWfYh/dQnAwp7K45cjRMjoF3A1kH98A0OzNGPOJxaTmnfnZ2t5nswdR1auMse8R8oEJAVYRcYYGNMuCNGrTsvHN5qxEi7QYVwGpa9w2YbV9//Ufx68geZ0PH/O/cO8oH3IiPViO1QkbNcSwb/0pLkFO+6Zdo9PVEikQxHG6VQMpH6QZgYGKBAm+vAIwrGFyNYnkeZsvvKzMoMy45MZkp1aA3jTeaWLyKuR2J5JkTvwwTl6EVgGZ7tIG+jNCho5GfddGDcA/0K920FKUnlR+/WZjI3ecqVfcp4XVs4u2axTl4y6wRTmebN+MBbsKRYyZ65M/a3/FhDVbPlgBbo+aCtxFIPXQ+NDdram7gSUsAnuBcLEWD6aK0Shi3qe7MTUnPLzqSlArBHBY4pS2hzPo+uxr+ZIq1SmrxyALRSNeb7hDDCQ5K38TKI0IcqxeBTLL9tB0Czmwz+odNhhls8efbWMeWCIgiSh/qyl5Wbtv7hDXbCgpumWY+ouA3Zbw5u7qVghgEOU/6l9Fx3dSgKYIF9eJICVieleg+3QQ0UBALpEuNTAa/cf50/pbz+ZkeqkCFxitfTrDRNFGXrzwjvOcjqm/pF0k5oPTtl9mLEPKCh9IZFSgwA+MW3ZiRm/H/P2kLZ7HBoVQpIIzL8U8k+o1yF2WF7WXiYKyj24/2UtplWLfYculkFTvx8r0M+klGzYgGw9A8jfNWIbvdiVuNODzDfXbQTKzOOWTT5x48GSi0K9olH5Tz6Fe+xDNVItIXSMkiyAz6q4o07DD4GkmWBPzmWrVsb9ppiGggWQ+Egx5Gswa9MdrE5rqkQ3L3Jylq1L1gs7IqaOTH/+13xArNLHA8615O7TjVS1y5JAtHludRfF0v7S5kuDB1SlROleiGPGWdrD+hkjwewctsQAay0UmI+IxZ1iCERmHKz54PUj82qfAGo/Yn+Tc0GY/nE1Pd5olQ+ZGeujZa8RAdQn0ApY7ft4RM+XnxGnwrvT+mC/HbWi/iHUZgICmhOWKu4wqKH77Ofy4QeqNaZ40W0ceHYg2/VGH7KZevEd0iF+5qIBxD+rbsh9300fWW/Y8iUO0Y+/pSr+HXXHxvrR/7Nl3Lnfr/Dl+barKfkyTmAfTZrOlcZXwZZ1oILsQW2xKr6GQGPV4kj0RmPpykm2C7O/K6Mir6KIDxzaZpTC0QiTw7cLD/Nm0EUncNSP/0TMw==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(10070799003)(7055299006)(38070700018);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 7nV5LVZTl35yGpe1nqDLXCQNSSTBiulqk4+fC9as4GOQX7L7DoKIQD2W9Esj4GZlI1rj4We3WjDbom7btglFL10FVeAIKeTrNtJlelk+scLq8Ugqum6LNma8h5ATPPlDZlAa/I3mk8HHz6BUDuvK9VmkraLUAfvjsdiONhOkrAuf2P4hp9P4+w/Ocutxvbq03kv4tvcS3kI5dp/VKNKY8nfm1aOLbdDjkpMdkyRIo4lEQMChq7NaEK7AHTpeX1+oEsX++3rAWAO/KBNRkuw/SYaCZOu7IjqAR8q7u7r7MCkcrCrcyz2izIb73H/dQmDw8t50iP0LDO/rF5/6qW44EHS4PBq41EXPPK3ClqSY5nuDmRs7NkWTL0HJMzBRpxzFoOVMlfQvm4eWdzjAqWejmzLp5eVLDBAkogSKRyxZWrdnswV4YFLgljxWdxOpt0djlGunNJ10iIruL9MzRmDL1jdwd0vqaFmQL6CotH3oANCy9gIbsY6EyxkAz6RvCvV0GgG3HGM3G4e9IxFiuCeMCP+PfeiBnb/GWDfhEg0zzsGTbXGi8LB4up4s0HhQlAc5aiKcx/y+zkDIKk0kYCdnYzrtPqCu0nzNRs1BvAZHaGzFCQVUm6D1+OIKJ8q+NwqTZizk1JpWVtaOHN1fNPpabmGZ4yc9U+NQtC21Dl/6jEIxa4n1+7d84KqizoVzlcTfUAzgXX/5z4cxwTligtcHN59EnQ4fj5qa673t3mWmEJgBRIfvmX7STluFZSgNo3FSpRWs09ozLJs/407dJKaW51d/Sc/6+hzb/5xIV0OyHWr031ll7I7twBL7gBIRSTeUx9/WJ2HuLPjKqcmxyBpHjr35GGnWwr0InjLmpIZpqGmhgqhSOndSwLLMRiX3ZUG5LkoevHwCv82FiZ81mj5Yx0gok8cl3ftVKK91NnoiUX1YXFg0A5WlBZxMuWLFHY12nHRHwAZYUd6FUXB+bIH533EwIGN9dmX2EiOC6rBhwj5o3gLBM47knilRdaqR0/TjDs5JBJG9epCGm6/wgYYFEc43t1J2LMnUDTzYLofr2v7kBB+Ii4Bsk6WM809A9mn30dL8kmLT3ldY0An7L+0/KNjKN8a4cwWfMNxu4ezx82NZKeNI+juMf9cZqHSP60t5FmL9ZhUZo/qJN8L4oSwIcBb3ciGjLNiwV77jJ6ShfodOo0Ay8Uadxb3KGqdbRXJGh+yjlAdFVSdLBhsK2hjFekYzER8MNP3vOJl1Xzf/ITp7WgjJw/GEoHGUBQIpMbYTpOHSvQmwmLPdC+p1049y2Mzu2+mgL0acG+8Lif+5P/puqVyIZ/3YO1b/l9ELQKbMMH121QG/IG3H+hGFkaakBiJO9A8cqezKnfP7GwY/cLvWeO1uVgvH0Uu5mP6K2B5JLh6Y9njP6DBK23YW/tsOIqE90DzQi3hu1/blLcJEHUg4P1/6x+181sOCKzYA6dewk8V1ebtSfU2j+uYOdSSj+JVlYojK68sqFrQg3aaCyv/6EgJK5Um07LhEnHI6G1D0TWrrQCs7A0uJT78v5Yp9jDH53gXOUE1Vjss/yzFQR9lpohHTLz/nQPkCsVOETPxRBNYyZtg5ysyljhdvVGubkQy8Goshka+VcKtf2gYrzT9sTn4kbldxhuTHAIw7wbV1+2NIe4a/t6PHbmiHeC06+g==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c6538c6-9f1c-4ad1-4ecd-08dd355ba88d
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2025 11:56:34.2041 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1e52LrWh8bDwpY4fh+BMHKHM2OFXcWsln/HJs3b4kUPgdjGPew1vWOcSoo5zawBV/W2uU/1ctAyT6OAtsfJVbu/podnKAN07nTIj62jhar8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0P190MB2186
Message-ID-Hash: F2VETPHBYBSRI52BLGZXWIMNX4DAUYAJ
X-Message-ID-Hash: F2VETPHBYBSRI52BLGZXWIMNX4DAUYAJ
X-MailFrom: esko.dijk@iotconsultancy.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Ee2W26ncFB4wXTtTI3id9HK18gc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>
Right, that's a good point. Agree. For the cBRSKI case the Registrar automatically gets the IDevID cert chain up to the vendor-defined trust root, through the DTLS handshake process. For the PRM case, the Registrar automatically gets it in the signed PVR (after the edit you proposed). For both cases, the Registar needs to receive the trust root via some out-of-band/external means to be able to verify if the right device, or device with the expected vendor, is being onboarded. It's then a vendor decision what that trust root exactly is: (one of the) sub-CA(s), root CA, or a PKI based CA. (This is the variability I mentioned.) Esko -----Original Message----- From: Fries, Steffen <steffen.fries@siemens.com> Sent: woensdag 15 januari 2025 12:20 To: Esko Dijk <esko.dijk@iotconsultancy.nl>; Michael Richardson <mcr+ietf@sandelman.ca>; anima@ietf.org; Werner, Thomas <thomas-werner@siemens.com> Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR Hi Esko, My expectation would be that the vendor includes the certificate chain up to the trust anchor he would also provide externally for IDevID validation. This would then be the trust anchor configured at the MASA and also the one provided to the Registrar and can be the root CA certificate or some intermediate. So the only point I would see is to rely on the availability of the trust anchor provided by the manufacturer for IDevID certificate validation. Best regards Steffen > -----Original Message----- > From: Esko Dijk <esko.dijk@iotconsultancy.nl> > Sent: Wednesday, January 15, 2025 10:53 AM > To: Fries, Steffen (FT RPD CST) <steffen.fries@siemens.com>; Michael > Richardson <mcr+ietf@sandelman.ca>; anima@ietf.org; Werner, Thomas (FT RPD > CST SEA-DE) <thomas-werner@siemens.com> > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on > signing the PVR > > Ok for me. > > We have to keep in mind though, that while a MUST requirement sounds clear (it's > included - as opposed to a SHOULD), this requirement itself does not necessarily > lead to predictable behavior of what the Pledge will include! > For example, > * one Pledge from vendor A may include its IDevID EE cert plus one sub-CA cert > (2 certs), as it considers the sub-CA cert to be the "trust anchor" it shares with > MASA (as the intended receiver of the PVR). > * one Pledge from vendor B may includes its entire chain up to the root CA (e.g. 3 > or 4 certs), as it considers the root-CA cert to be "trust anchor". > > Effectively the device vendor decides what the "trust anchor" is. > > In this sense, there's still some variation and optionality as to what the Pledge will > include. (I think we discussed this in the call and it seemed ok to have that.) > > Esko > > -----Original Message----- > From: Fries, Steffen <steffen.fries@siemens.com> > Sent: woensdag 15 januari 2025 10:46 > To: Esko Dijk <esko.dijk@iotconsultancy.nl>; Michael Richardson > <mcr+ietf@sandelman.ca>; anima@ietf.org; Werner, Thomas <thomas- > werner@siemens.com> > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on > signing the PVR > > Hi Esko, hi Michael, > > In PRM the Registrar-Agent adds the agent-signed-data when it triggers the pledge > to create the PVR. It is a signed object to proof specifically to the registrar, with > which registrar-Agent the pledge was in contact. It could convey the certificate > chain of the Registrar-Agent certificate, but we described that the Registrar is > configured with the information to validate the Registrar-Agent, so there is no need > to include the certificate chain for the Registrar-Agent certificate. > > Other than that, the change to a MUST in JWS-Voucher for including the certificate > chain in the voucher and following also in the voucher request, also simplifies the > corresponding sections in BRSKI-PRM for PVR and RVR. Up to now, as the > inclusion of the certificate chain was handled as SHOULD in JWS-Voucher and > PRM contained the handling for both cases, if the certificate chain is included and > if not. The latter required additional information to be available at the registrar, as > in PRM it also verifies the PVR. This essentially means that wen can simplify the > two subsections for the JWS-Header handling for the Pledge Voucher- Request > (PVR, section 7.1.2.2) and Registrar Voucher-request (RPR, section 7.3.4.2) as > JWS-Voucher is requiring inclusion of the certificate chain. > I will do that change and submit an updated version by tomorrow. > > Best regards > Steffen > > > -----Original Message----- > > From: Esko Dijk <esko.dijk@iotconsultancy.nl> > > Sent: Tuesday, January 14, 2025 11:53 PM > > To: Michael Richardson <mcr+ietf@sandelman.ca>; anima@ietf.org; > > Werner, Thomas (FT RPD CST SEA-DE) <thomas-werner@siemens.com>; Fries, > > Steffen (FT RPD CST) <steffen.fries@siemens.com> > > Subject: RE: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements > > on signing the PVR > > > > > The *Registrar*, however, might not have them all. > > > > In cBRSKI the Registrar does get them all from the DTLS handshake. But > > agree that for PRM this doesn't work in the same way. > > I didn't read PRM recently - does the Agent add a signed object > > stating the IDevID cert chain that it has seen from the Pledge...? > > > > If not: then either the cert chain needs to be in the signed PVR, or > > we need extra requirements on the Registrar to get these chains > > beforehand which may not always be practical. > > > > We have some discussion (to be continued) whether the Registrar can be > > expected to be preloaded with all CAs in the chains, or a subset of > > only the highest sub-CAs, or only the root CA ? > > The more the Registrar already knows, the less the Pledge has to send > > in its PVR, given that the MASA would know all its own CAs for sure. > > > > Esko > > > > -----Original Message----- > > From: Michael Richardson <mcr+ietf@sandelman.ca> > > Sent: dinsdag 14 januari 2025 21:00 > > To: Esko Dijk <esko.dijk@iotconsultancy.nl>; anima@ietf.org; Werner, > > Thomas <thomas-werner@siemens.com>; Fries, Steffen > > <steffen.fries@siemens.com> > > Subject: Re: [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements > > on signing the PVR > > > > > > Esko Dijk <esko.dijk@iotconsultancy.nl> wrote: > > > Now the target recipient of the PVR is the MASA. (Again for PRM this > > > may be different and include Registrar as well...? But not in BRSKI I > > > think.) So the requirement on the Pledge is it SHOULD include in the > > > PVR all the certificates needed for the MASA to build the complete > > > chain. > > > > Since the manufacturer created the IDevID for the pledge, I would > > think it (the MASA) has all the required subordinate certificates. > > The *Registrar*, however, might not have them all. > > It's a tussle. > > > > > The MASA is this solution needs to store all the cert-chains for all > > > the Pledges it supports – including their IDevID EE certificates -- an > > > extra burden on MASA, compared with BRSKI, but one which helps us > > > achieve the smaller size of PVR. So cBRSKI changes the “SHOULD” > > > requirement from 8995 to a SHOULD NOT in Section 9.2.2. > > > > I don't think it's a burden :-) > > > > > A registrar accepts or declines a request to join the domain, based > > > on the authenticated identity presented > > > > > It doesn’t say where the IDevID identity should come from – PVR or the > > > (D)TLS handshake supplied certificates. Having only one source should > > > be fine ... ? > > > > Yes. > > I prefer getting it from the PVR. > > That's much easier in a PRM situation. > > > > -- > > Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide
- [Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requ… Esko Dijk
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Michael Richardson
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Esko Dijk
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Fries, Steffen
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Esko Dijk
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Fries, Steffen
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Esko Dijk
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Michael Richardson
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Esko Dijk
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Michael Richardson
- [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM … Esko Dijk