On Tue, Aug 06, 2019 at 03:01:18PM +0000, Kent Watsen wrote: > 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.
I ranted about the need to better describe the common architecture already in prior emails to the anima list. Complexity is in the eye of the beholder. I like the modularity/flexibility that NetConf provides, but of try to find someone who understands how to duplicate the full enrolment process of BRSKI+EST with equivalent NetConf supported Yang object models (especially for TA and Cert enrollment). And then find more constrained devices that would more happily go with that more (IMHO) flexible model. But given how constrained devices also do not like TLS of BRSKI, it would be great if we could come up with a single preferred transport to use with either server-controlle workflow (like SZTP/Netconf) and client-side controlled (like BRSKI). > 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>. I think what you say is not specific to ACME but true for any RA<->CA protocol. The fact that NetConf/SZTP allows to enrol the certificate any time later is a key difference. I think architecturally, you want to make it as soon as possible, but for example you may still want to first do some additional attestation before the key enrollment. This is where BRSKI+EST is a lot less flexible in design, but given how i think there is no model for attestation in IETF, its hard t make the point now. The only ACME specific thing i can think of are the mechanisms for the RA to prove to the CA posession of a domain-name/prefix. That i think is independent of the key-store. More related to the ability of the RA to create DNS entries. No idea if there is a yang model for that (would be nice). Cheers Toerless > Kent > > > > > On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > > > FYI, Its up on github now: > > > > https://github.com/upros/brski-cloud <https://github.com/upros/brski-cloud> > > > > > > From: Anima <anima-boun...@ietf.org <mailto:anima-boun...@ietf.org>> On > > Behalf Of Owen Friel (ofriel) > > Sent: 06 August 2019 14:05 > > To: Rifaat Shekh-Yusef <rifaat.i...@gmail.com > > <mailto:rifaat.i...@gmail.com>>; anima@ietf.org <mailto:anima@ietf.org>; > > iot-onboard...@ietf.org <mailto:iot-onboard...@ietf.org> > > 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 <iot-onboarding-boun...@ietf.org > > <mailto:iot-onboarding-boun...@ietf.org>> On Behalf Of Rifaat Shekh-Yusef > > Sent: 02 August 2019 19:09 > > To: anima@ietf.org <mailto:anima@ietf.org>; iot-onboard...@ietf.org > > <mailto:iot-onboard...@ietf.org> > > 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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
