Skimming quickly, I see now the direction to go to a cloud registrar to be redirected to a local registrar. I feel compelled to point out that this is exactly what SZTP (RFC 8572) does, or at least, supports. Actually, as a more general statement, it was originally said that the two WG's approaches were different, but they are now becoming more and more alike. Well, since SZTP is published already, it's more like the ANIMA approach is becoming more like SZTP, albeit seemingly with more complexity.
Regarding ACME integration during bootstrap, I think the basic desire is to configure a device to obtain a certificate via ACME, configuration which so happens to be provided at the time of the bootstrap event, but could also happen at anytime thereafter. Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore <https://tools.ietf.org/html/draft-ietf-netconf-keystore>. Kent > On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) <[email protected]> wrote: > > FYI, Its up on github now: > > https://github.com/upros/brski-cloud <https://github.com/upros/brski-cloud> > > > From: Anima <[email protected] <mailto:[email protected]>> On > Behalf Of Owen Friel (ofriel) > Sent: 06 August 2019 14:05 > To: Rifaat Shekh-Yusef <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; > [email protected] <mailto:[email protected]> > Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment > Automation with ACME using BRSKI > > Hi guys, > > After the meeting and from corridor conversations with Toerless, I had > actually already started on such a draft. > > What I have started so far is attached. Its not on a public repo yet, but > will put it there. You are already named on it Rifaat, happy to add you too > Michael and you can help figure out some of the open redirect options > outlined in it J > > My high level thoughts on this were to keep the ACME specifics out of the > draft, and use the draft to define the cloud RA behaviour, and the pledge > behaviour when interacting with the cloud RA, and the various cert, CA, TLS, > redirect, etc. details. The fact that the RA (whether cloud or local) *may* > use ACME to talk to the CA is transparent to the pledge. > > I was thinking that the ACME specifics could be covered in a different draft > based on mergingdraft-yusef-acme-3rd-party-device-attestation and > draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics > in this one. > > Thoughts? > Owen > > > > > From: Iot-onboarding <[email protected] > <mailto:[email protected]>> On Behalf Of Rifaat Shekh-Yusef > Sent: 02 August 2019 19:09 > To: [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME > using BRSKI > > All, > > During the last IETF meeting in Montreal we had a side meeting to discuss the > deployment automation of ACME issued certificates to devices, and the > potential > use of the BRSKI mechanism to help with this. It was clear from the > discussion > that BRSKI can be used to help address this use case, and that further > discussion is > needed to define the needed enhancements to BRSKI. > > The current BRSKI mechanism only briefly discusses the Cloud Registrar option > in > section 2.7, which could be used to help address this use case. > > Michael Richardson and I had another meeting over lunch yesterday to further > discuss this and we decided to work on a new draft to describe the issue and > define a solution. > > Because of vacations and other commitments, we will try to publish the first > version of the draft early October. > > Regards, > Rifaat & Michael > _______________________________________________ > Anima mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/anima > <https://www.ietf.org/mailman/listinfo/anima>
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
