Re: [Iot-onboarding] [Anima] Device Certificate Deployment Automation with ACME using BRSKI

[Toerless Eckert <[e-mail]>]

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) <[e-mail]> wrote:
> > 
> > FYI, Its up on github now:
> >  
> > https://github.com/upros/brski-cloud <https://github.com/upros/brski-cloud>
> >  
> >  
> > From: Anima <[e-mail] <mailto:[e-mail]>> On Behalf Of Owen Friel (ofriel)
> > Sent: 06 August 2019 14:05
> > To: Rifaat Shekh-Yusef <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> > 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of Rifaat Shekh-Yusef
> > Sent: 02 August 2019 19:09
> > To: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> > 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