Re: [Netconf] zerotouch issues found while preparing -20

[Kent Watsen <[e-mail]>]

I found another issue while updating my PoC code to the current draft.  The issue comes from the draft's "zerotouch-information" artifact, a PKCS7 structure, only supporting a JSON-encoded payload.  The reason why it only supports a JSON-encoded payload was discussed on list before, but it goes to aligning with what draft-ietf-anima-voucher does.  The issue manifests itself when the payload encodes "onboarding-information", which has an 'anydata' node called "configuration".  Being 'anydata' inside a JSON-encoded document means that the configuration itself must also be JSON-encoded, but this is a problem for devices that don't support JSON encoded configuration, and that it's not possible for a bootstrap server (that may not have access to the YANG for the configuration) to generically convert the JSON to XML. Stated the issue another way, the current solution couples the encoding of the submitted configuration with the encoding of the envelop that's used to convey the configuration.  To address that, I propose replacing the 'anydata' node with a 'leaf' of type binary.  I don't foresee any interoperability issue with this change, as already the data sent to the device must be device-specific.  To be clear about this proposal, here is a commit that illustrates the change:

 https://github.com/netconf-wg/zero-touch/commit/14d92eec946b50eb980b51670ace6ce8bf2e2334

While this is a technical change, it doesn't change the solution in a material way, so I'm hoping that it doesn't necessitate another last call to approve.  If no objections are raised, I'll also apply this change to the pending -20 update.

Separately, here are a couple other things we might consider doing:

1) move from PKCS7 to CMS (RFC5652).   CMS is IETF's version of PKCS7.   It's practically identical.  The IESG requested this change when the anima-voucher draft went through its IETF Last Call, and so I expect the same change will be requested for this draft as well.

2) modify the draft's statement that devices MUST send an IDevID certificate to one that says devices MUST send an IDevID certificate and/or HTTP-level authentication.   This wording is consistent with RFC 8040 Section 2.5 and, by allowing HTTP-level authentication, it will better represent products shipping by a number of vendors, whereby the installer can, for instance, type in a password into the device while it's booting.  This appears to be a popular low-barrier choice, as implementing IDevID is not easy.

Thoughts?

Kent  // contributor