Or = in general, if the key is configured as hidden, I think it should
NOT have a public key and alg in the config (can be ensured = with
"must"). However, they must be present in the = operational state.

Okay, but in thinking about going down that = route, I'd rather use a special enum/union type values to denote the = absence of these fields than to mark the nodes mandatory false. = Personally, I think it's better to duplicate the values into = configuration as it does no harm and it makes them easier and more = consistent to work with (e.g., clients need the public key in order to = encrypt data destined to the device). Really, I don't want any = keys in <operational>, but feel that we have to make an exception = for the manufacturer-generated keys (unless, to your comment above, we = could mark them as immutable in the configuration). [PS: in a = previous life, I used per instance metadata when a node was = immutable.]

3) privileged admin = encrypts a well-known (secret to the organization)
symmetric= key using the public key from the manufacturer generated
asymmetric key, and stores the result (i.e., = <edit-config> into
keystore.

Ok. However, if the device = doesn't have a hidden
manufacturer-supplied key from step = 1 (no tpm), it would be useful if
the admin could install = this symmetric key so that it becomes hidden.
But that = action is no longer present in the model.

True, but it = seems strange that a device would have the ability to store hidden keys = without itself being shipped with a hidden key. We could add a set = of RPCs to manage the life-cycle of hidden keys, but I'd rather steer = folks to using NACM in such cases, as I don't think it makes sense to = either have 1) persistent user-created operational state or 2) = persistent configuration that isn't configuration.

Or does this model *require* the device to have = such a key? If no tpm
exists, then it can exist on = disk?

Not = required. For devices that don't have hidden keys, plain old NACM = could protect the encryption-key used to protect all the other keys in = the configuration. The primary benefit would still be present, = that keys subsequently generated by the device would be protected by the = encryption key. The downside would be that the encryption key = itself, when generated, could not be protected in the same way. = For such situations, it would be recommended that this key be = installed from a known-safe connection (i.e., via an air-gapped = system).

4) if replacing a device, load previous configuration. = Since all keys
should be encrypted to the same = symmetric key, it should load without
error.

Before loading the previous = config, the admin must do steps 2-3 on the
new device, = right?

Correct. = To be more clear, all steps except (4) would occur on a first = device and then, when an RMA is necessary, steps (1-3) would occur on a = second device, following by step (4) to migrate the configuration from = the first device to the second device, and then the remaining steps (5+) = would be business as usual on the second device.

[note: one issue here with the secret symmetric = key itself
being loaded again, but since it was encrypted = using to old device's
manufacturer generated asymmetric = key, the logic should be able to
handle it.]

Hmm, can you elaborate? It = seems to me to be a problem; it needs to
be re-installed = so that it is encrypted with the new device's public
key.

What is meant is = that the symmetric key would be created once on the second device, in = step (3), but because the old encrypted symmetric key was stored in = configuration (on the first device), when loading the configuration here = in step (4), it is as if the symmetric key is being created again on the = second device. But the logic on the second device should be able = to detect this anomaly (because the key would've been encrypted by the = first device's private key, and hence decryption should fail on the = second device) and thus the "duplicate" symmetric key would be = discarded.

Runtime:
5) whenever a regular = admin wishes to use a new key, they call the
generate-symmetric-key or generate-asymmetric-key RPC, = requesting the
device to generate a key for them, = encrypting the result using the
secret organization = key.
6) The RPC output returns the key value = (encrypted).
7) The regular admin uses e.g., = <edit-config> to store the key into
<running>.

Use cases:
0: normal (just = NACM-protected) keys: supported.
1: = manufacturer-generated permanently hidden keys: supported.
= 2: device-generated keys: supported.
3: = device-generated keys in config: supported
4: = permanently hidden keys: not recommended nor directly
=     supported, but one could always encrypt a key = with the
    device's public key, = thus generating a key that only the
=     device can decrypt, and hence effectively = permenently
    hidden.

Please let me know soon if you = object to any aspect of this or,
better, support it, as I = need to update the remaining drafts to
reflect these = changes at some point soon.

Also, if we go this route, this draft (keystore) needs more = text, and
also explain the use cases described above.

Agreed. I = also never documented the "generate-symmetric-key" and = "generate-asymmetric-key" RPCs...

Regarding "going this route", your response thus = far seems to be on the level so, would it be fair to say that you're = leaning towards thinking that it might be okay?

Then there are some details, e.g. why do we = have

   identity = asymmetric-key-algorithm {
=      description
=        "Base identity from which all = asymmetric key
=         encryption = Algorithm.";
   }

vs

   identity = encryption-algorithm {
=      description
=        "A base identity for = encryption algorithm.";
   }

Why isn't the latter called = "symmetric-key-algorithm"?

These identities (now = enumerations) are coming from the crypto-types module in a section = maintained by my co-author from Huawei who has even more crypto-clue = than I. My guess is that this is what they're called in IANA = registries for historical reasons.

/martin

Kent // = contributor