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

[Kent Watsen <[e-mail]>]

Hi Toerless,


> I ranted about the need to better describe the common architecture 
> already in prior emails to the anima list.

Good.  


> Complexity is in the eye of the beholder.

True, but it seems that getting a domain certificate and getting an initial configuration are at least two distinct steps in ANIMA, whereas they're rolled into one step with SZTP.   

While the comparison may not apply perfectly, for a long time in filesystems, the redundancy layer (e.g., RAID-6) and the volume management layer were distinct, but ZFS collapsed them into one layer, for the better.  I wonder if we might not have something like that here...


> 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. 

That paragraph didn't parse completely for me, but I get the sense that there is an incomplete view, in both directions, for how things work.   Ideally, I would be more active in ANIMA but, I've been so busy that I haven't had time.   Perhaps we could schedule a call to go over where/how SZTP can fit into the ANIMA 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 TLS, SZTP depends on TLS in a soft way, other bindings could be defined if needed.

Regarding which side controls the flow, I'm unsure if SZTP is server-controlled, at least, it is the device the initiates the connection to the server, but perhaps you mean what I'd refer to a post-bootstrapping steps that are needed to complete the full bringup.


>> 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.

Yes.


> 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.

I'm quasi-working with Henk on RATS...


> 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).


The keystore relation here is threefold:

  1) when shipped from manufacturing, the keystore may be pre-populated
      with the device's, e.g., TPM-protected asymmetric key and associated
      IDevID certificate.

  2) when deployed, an alternate LDevID certificate may be configured in
      the keystore.

  3) ACME or equivalent could be used to auto-update certificates as
      needed (the keystore model doesn't support this yet)


I'm not aware of a YANG model to configure a DNS server as of yet.


Kent