Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

>> There are two solutions being discussed here.  
>> 
>> The first regards how to enable a certificate to be configured for a key
>> in <operational> (e.g., an LDevID cert for a preexisting key).  Both
>> solution (A) and (C) give us this - a la RFC 8342 Section C.3.2.
>> 
>> The second is how to delete a "hidden key" created by a client (note here
>> that I'm distinguishing this case from hidden keys not created by a client,
>> i.e., in <operational>, which cannot be deleted).  Here's where the ideas
>> diverge:
>> 
>>   - with (A), we keep the "generate" action outside the list entry (thus
>>     results are in <operational>, and add a new "delete-asymmetric-key"
>>     action is needed.
>> 
>>   - with (C), the action is moved inside the list entry, thus the list
>>     entry node itself in <intended>, and hence can be removed from
>>     <intended> via a normal config operation (no special action needed).
>> 
>> I don't see an issue configuring certificates in either case.  As I wrote
>> above, both solution (A) and (C) give us this. (C) still has to handle
>> the case where the key is in <operational> same as (A).  With (C), it's
>> the 1% case, whereas with (A) it’s the 100% case.
>
> How can a key be in operational but not in config in (C)?  I.e., what
> is the 1% case?

Maybe too subtle, but in my first paragraph above said "e.g., an LDevID
cert for a preexisting key".  I'm referring to how, during manufacturing,
a private key and an associated IDevID certificate are created and loaded
onto the device.  This key and cert are immutable, but another cert could
be loaded for the same key.  This is the scenario captured in the example
in: https://tools.ietf.org/html/draft-ietf-netconf-keystore-05#section-3.2.
(search for "tpm-protected-key").  This is the 1% case.



>> They seem close.  For the purpose of creating a key, (C) is more
>> complicated.  For the purpose of deleting a key, (C) seems easier.
>
> For the purpose of creating a certificate (A) is more complicated.

How is that so?  Actually, it seems that (A) and (C) are identical
in this respect, from a protocol perspective.  The only difference
is in the backend, where it uses the RFC 8342 Section C.3.2 overlay
behavior.


> Depending on the answer above, (C) has the advantage that references
> (leafrefs) to a key can be require instance true.  With (A) they have
> to be require instance false, since some keys only exists in
> operational, which means that whenever there is a reference to a key,
> that model and code must be able to handle the case that the key
> doesn't exist.

Even with (C), some keys can be in <operational> - the 1% case, right?

Yes, if *all* keys had a presence in <intended>, then learefs to keys
could be "require-instance true".


Kent // contributor