Re: [netconf] ietf crypto types - permanently hidden

[Kent Watsen <[e-mail]>]

Hi Balazs,

> In case of crypt-hash, I can accept the extension of the crypt(3) schemes with a $0$ that sort of represents a hash() action, since it matches the original crypt(3) syntax.
>  
> In this case, I find it awkward to tell what to do with the data (verbs) as prefixes of the data.

Agreed, but we seem to be at an impasse and I thought this approach could get us over the line.


> I personally preferred actions better for this purpose.

It is my preference to use actions as well, but there's pushback there.  Maybe we could claim that the pushback is "in the rough" and press ahead regardless, but I'd rather avoid that if possible. 


> I assume that this representation also does not change the matter of “actions” affecting configuration (see ‘output’ values).

You mean, exploring this solution leaves the "is it possible for actions to affect configuration" as unresolved?  - correct, that discussion would remain open.


> Also validation of required input and output seems more complicated to me.

How so?


> The generate action returning the name of the key or optionally creating configuration sounded so far the closest match to me.

Understood.


>  I’m also thinking do we need the ‘generate-and-not-hide’ and the ‘install-and-hide’ use cases?

Actually, I view  ‘generate-and-not-hide’ as a very common case.  That is, ask the system to generate the key (because clients are lazy and security best practice), and let standard NACM rules protect the key.   I think that systems supporting user-generated "hidden" keys will be somewhat rare, to the extent that there should feature statements enabling servers to indicate if they support the ability or not.


---

I'm growing weary of this discussion.  Perhaps we should do even less for the first release of the crypto-types module.  That is, instead of:

   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
         + '|<value-to-be-generated(-and-hidden)?>'
         + '|<value-to-be-hidden>[A-Za-z0-9+/]+[=]{1,3}';
       }

we have:

   leaf private-key {
     nacm:default-deny-all;
     type union {
       type binary;
       type string {
         pattern
           '<permanently-hidden>'
         + '|<encrypted by="*">[A-Za-z0-9+/]+[=]{1,3}'
       }


This removes the "verbs" (as you call them) and thus leaves open possibility for either "verbs" or action statements to be added in some future revision.   This subset still supports the critical use-case of a manufacturer-generated private key for a secure device identifier (i.e., IDevID).    Unfortunately, it does not support the security best practice use-case of having the device generate the private key.  The IESG (Security Directorate) may or may not be okay with this (obviously the shepherd would have to bring it to their attention), but perhaps it's worth testing their resolve and see what happens?


Kent // contributor