Hi Mohamed, Ah sorry, forgot to include the info regarding open-brski. That implementation is an example implementation of BRSKI-PRM and parts of cBRSKI and was done as part of a master thesis. The implementation bases on OpenSSL and utilizes to my knowledge TLS 1.2.
Best regards Steffen > -----Original Message----- > From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> > Sent: Thursday, April 10, 2025 6:04 PM > To: Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org>; The IESG > <i...@ietf.org> > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; > i...@kovatsch.net; t...@cs.fau.de > Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-anima-brski-prm-18: > (with > DISCUSS and COMMENT) > > Re-, > > Thanks, Steffen. > > I think we are almost there, modulo the "paused" item and recording the > limitation. > > > > BTW, what is currently supported by implementations such as > > open-brski? > > [stf] > > > > [Med] It seems this was one was incomplete. I'm interested still interested, > but > that's fine if we don't have an answer. Thanks. > > Cheers, > Med > > > -----Message d'origine----- > > De : Fries, Steffen <steffen.fries=40siemens....@dmarc.ietf.org> > > Envoyé : jeudi 10 avril 2025 17:35 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > The > > IESG <i...@ietf.org> Cc : draft-ietf-anima-brski-...@ietf.org; > > anima-cha...@ietf.org; anima@ietf.org; i...@kovatsch.net; > > t...@cs.fau.de Objet : RE: Mohamed Boucadair's Discuss on > > draft-ietf-anima-brski- > > prm-18: (with DISCUSS and COMMENT) > > > > > > Hi Mohamed, > > > > Thanks for your comments. As last time, I leave the comments with > > reactions and dropped the closed ones for easier reading. > > The draft with the updates has been put on the usual place in github > > (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feur > > > 03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%25252&d > > > ata=05%7C02%7Csteffen.fries%40siemens.com%7C1afd21e6721341eb8a9308dd7 > 8 > > > 495eba%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6387989786909 > 06742 > > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > AwMCIsI > > > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata= > crY > > y0R759q139IOXkuJl4imtDXICDfeHhLlSkSnn3M4%3D&reserved=0 > > Fgithub.com%2Fanima-wg%2Fanima-brski-prm%2Fblob%2Fmain%2Fdraft- > > ietf-anima-brski- > > > prm.md&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C94792fe975f > > > 94fd8972f08dd784543bc%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > > > C638798961115558475%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydW > > UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > > > D%3D%7C0%7C%7C%7C&sdata=0ibhUGU1HfNOMvByzeiLbmnrUu5ruMeye%2B > %2FYND > > Ev7iE%3D&reserved=0). > > > > Best regards > > Steffen > > > > > -----Original Message----- > > > From: mohamed.boucad...@orange.com > > <mohamed.boucad...@orange.com> > > > Sent: Thursday, April 10, 2025 7:11 AM > > > To: Fries, Steffen (FT RPD CST) <steffen.fr...@siemens.com>; The > > IESG > > > <i...@ietf.org> > > > Cc: draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > > > anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de > > > Subject: RE: Mohamed Boucadair's Discuss on > > > draft-ietf-anima-brski-prm-18: (with > > > > > > > > > -------------------------------------------------------- > > ---- > > > > > > > DISCUSS: > > > > > > > -------------------------------------------------------- > > ---- > > > > > > > # DISCUSS > > > > > > > # Compliance with HTTP BCP (RFC9205) > > > > > > > > > > > > > > CURRENT: > > > > > > > If the pledge is unable to create the PVR, it SHOULD > > respond with an > > > > > > > HTTP error status code to the Registrar-Agent. The > > following client > > > > > > > error status codes SHOULD be used: > > > > > > > > > > > > > > The use of normative language is IMO not compliant with > > the > > > > > > > guidance in RFC9205, about error handling. > > > > > > [stf] I created a new issue for this: > > > > > > From RFC 9205 I understood that we could use the HTTP > > status > > > > > > codes in this way. What would you suggest here? > > > > > > > > > > > > > > > > [Med] A simple fix here is to remove the normative language. > > > > > Listing the appropriate codes is definitely right, but need > > to > > > > > redefine the error codes, just be affirmative. For example, > > an > > > > > entity will return 404 when there is no resources, etc. > > > > [stf] Hm, after the discussion in the design team, we are not > > quite > > > > sure about your concern. Is it the one.-to-one mapping > > referenced in > > > > section 4.6 of RFC 9205 or the understanding we re- define > > status > > > > codes? > > > > > > > > > > [Med] I'm afraid that you are redefining those. We don't need > > new > > > normative HTTP behavior here. I suggest we simply make this > > change > > > (and similar) > > > > > > OLD: > > > If the pledge is unable to create the PER, it SHOULD respond > > with an > > > HTTP error status code to the Registrar-Agent. The following > > client > > > error status codes MAY be used: > > > > > > * 400 Bad Request: if the pledge detects an error in the > > format of > > > the request. > > > ... > > > > > > NEW: > > > If the pledge is unable to create the PER, it responds with > > an > > > HTTP error status code to the Registrar-Agent. The following > > client > > > error status codes can be used: > > > > > > * 400 Bad Request: if the pledge detects an error in the > > format of > > > the request. > > > .. > > [stf] Okay, got it, made the changes as proposed for the different > > HTTP status codes > > > > [Med] Thanks. > > > > > > > > > > # Cluster with 8366bis > > > > > > > > > > > > > > CURRENT: > > > > > > > > > > > > > > The JSON PVR Data MUST contain the following fields > > of the "ietf- > > > > > > > voucher-request" YANG module as defined in > > > > > > > [I-D.ietf-anima-rfc8366bis]; > > > > > > > > > > > > > > I think this spec should be clustered with 8366bis. > > There are > > > > > > > several structure that used in this document and which > > depends on what is defined in 8366bis. > > > > > > > Changes to the bis will have implications on this one. > > > > > > > > > > > > > > With that in mind, I tend to suggest holding approval of > > this > > > > > > > specification till we finalize the bis spec. > > > > > > [stf] As indicated by Michael, we already have a cluster > > for > > > > RFC > > > > > > 8366bis and further drafts related to BRSKI variants to > > take > > > > > > care of mutual influences. I opened an issue > > > > > > > > > > [Med] ACK. > > > > [stf] Also discussed in design team meeting today. It is less > > about > > > > changes in the draft but more to the processing. The intention > > is > > > > that all other BRSKI variant documents currently handled will > > go > > > > into MISSREF, as draft-ietf-jws-voucher waiting for 8366bis. > > 8366bis > > > > collects considerations from the different documents and is > > likely > > > > not to lead to addition of new information in the respective > > drafts > > > > (at least that is the intention). > > > > > > > > > > [Med] I would be more comfortable if I had more stability signs > > of > > > 8366 ;-) > > > > > > That's said, I think that I have the discussion I wanted to > > have. I > > > leave it to Mahesh to decide. > > [stf] Okay, agreed > > > > > > > > > > > # Requires TLS1.3 > > > > > > > > > > > > > > CURRENT: > > > > > > > As already stated in [RFC8995], the use of TLS 1.3 > > (or newer) is > > > > > > > encouraged. TLS 1.2 or newer is REQUIRED on the > > Registrar-Agent > > > > > > > side. TLS 1.3 (or newer) SHOULD be available on the > > registrar, but > > > > > > > TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be > > available on the > > > > > > > MASA, but TLS 1.2 MAY be used. > > > > > > > > > > > > > > Please update to take into to reflect draft-ietf-uta- > > require-tls13. > > > > > > [stf] I saw that there was already discussion on this > > issue. I > > > > > > created a corresponding issue as We will discuss the use > > of TLS > > > > > > 1.2 and if there is a desire to also allow or existing > > pledges, > > > > > > that may have no option to only allow TLS 1.3, we would > > add a > > > > > > note as suggested and explain the necessity. > > > > > > > > > > > > > > > > [Med] ACK. I'm neutral on the outcome here, but I'd like we > > back > > > > > the design and include some reasoning if we don't follow the > > UTA reco. Thanks. > > > > [stf] BRSKI-PRM is an extension of existing BRSKI, which > > requires > > > > TLS 1.2. We aligned with that and also included it in BRSKI- > > PRM. > > > > TLS1.3 is currently widely used in browsers, but industry > > adoption > > > > is not as fast. There are constraint devices using SDKs, which > > are > > > > not updated fast. > > > > We enhanced the part with following to state the consideration > > of > > > > the uta draft.: > > > > OLD > > > > As already stated in {{!RFC8995}}, the use of TLS 1.3 (or > > newer) is > > > > encouraged. > > > > NEW > > > > As already stated in {{!RFC8995}}, and required by {{I-D.ietf- > > uta- > > > > require-tls13}}, the use of TLS 1.3 (or newer) is encouraged. > > > > > > > > > > [Med] I suggest we pause on this one and reflect the outcome of > > the > > > ongoing discussion. > > [stf] Okay, agreed > > > > > > > > I would at least see in the text a brief mention of the SDK > > > limitations you mentioned. > > [stf] Yes, it is likely good > > > > > [Med] ACK > > > > BTW, what is currently supported by implementations such as > > open-brski? > > [stf] > > > > [Med] It seems this was one was missing. I'm interested, but that's fine if > we don't > have an answer. Thanks. > ______________________________________________________________________ > ______________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or > copied without authorisation. > If you have received this email in error, please notify the sender and delete > this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
