Re: [netconf] [Anima] Reuse of SZTP-CSR YANG definition in BRSKI-AE

[Kent Watsen <[e-mail]>]

Hi Michael,

>> [future threads about SZTP should CC NETCONF, the WG that
>> published/maintains SZTP]
> 
> Yes, and not netmod?

Correct.  Though questions regarding the YANG language are best post to NETMOD.


>    sf> In one use case, the pledge has no direct connection to the registrar
>    sf> and a registrar-agent communicates with the pledge. In that specific
>    sf> case we do not have a TLS connection between the pledge and the
>    sf> registrar-agent and protect the exchanged objects by an additional
>    sf> signature. This is done by embedding the necessary information into a JOSE object.
> 
> ...
> 
>    sf> The question
>    sf> (https://github.com/anima-wg/anima-brski-async-enroll/issues/10) now
>    sf> is, if this construct is possible, as we are just using a subset
>    sf> (sztp-csr:csr) of the YANG  module " ietf-sztp-bootstrap-server" from
>    sf> draft-ietf-netconf-sztp-csr?
> 
>    kw> This is not possible.
> 
> I feel that the question might have been so specific that it didn't match.
> 
> My thought was to do CORECONF (possibly using CoAP over BTLE), to retrieve a
> CSR from a device.  It seems to fit right into the ietf-sztp-bootstrap-server
> pattern to me.
> 
> So, I'm unclear why ietf-sztp-csr:csr-support couldn't be used.
> Is it because the module augments sztp, and we don't need it all?

In part, but also because what you want is buried inside a definition and there is no mechanism to cherry-pick inner-nodes.


> We really just want container csr-support, csr-generation, csr, ???
> 
> Maybe we could chat about this more.
> We have a regular Thursday 9:30 EST design team.
> 
>>> The alternative would be to define an own module modeled in a similar.
> 
>> You can do this.
> 
> I think that we can have some common mindshare here.

One option would be to move stuff into ietf-crypto-types…as that module already defines a number of grouping statements for handy structures.  That said, these structures are not context-free…they are very much entwined in a specific dialog that is rather specific to bootstrapping processes.  [FWIW,  just adding “cmc” and “cmp" typedefs to crypto-types, alongside the existing “csr” (e.g., “p10”) typedef, might be a good thing]

Another option would be to move stuff into grouping statements, in the same module, that are immediately.  In theory this would have no impact to the on-the-wire format.  However, it’s somewhat late in the process to entertain this, as the draft is in the AD queue (AD-review was just posted today) and no doubt we would dicker over how many groupings to create and whether they should be put into another draft to whitewash out the SZTP-stint.  Is it proper to reset a NETCONF publication for another WG?  Rob?


K.