Re: [Netconf] Mandatory local configuration in Keystore groupings

[Kent Watsen <[e-mail]>]

// All, I plan to update this set of drafts before the cutoff, to address 
// the few items that have come up here, as well to add (finally!) a fix
// for "Should algorithm identities be moved from ietf-[ssh/tls]-common
// to crypto-types?" issue from IETF 102 (I've been working with a few
// cryptologists, and we have a proposal that we'd like to put in for
// review).  That would leave just the "Add support for TCP Keepalives?"
// issue remaining, for which I still don't have a good answer.


Hi Balazs,

> One more issue. There are 3 local-or-keystore definitions in 
> keystore. For example:
>
>  grouping local-or-keystore-asymmetric-key-with-certs-grouping {
>    description
>      "A grouping that expands to allow the key to be either stored
>       locally within the using data model, or be a reference to an
>       asymmetric key stored in the keystore.";
>    choice local-or-keystore {
>      mandatory true;
>      case local {
>        if-feature "local-keys-supported";
>        uses ct:asymmetric-key-pair-with-certs-grouping;
>      }
>      case keystore {
>        if-feature "keystore-supported";
>        leaf reference {
>          type ks:asymmetric-key-ref;
>          description
>            "A reference to a value that exists in the keystore.";
>        }
>      }
>      description
>        "A choice between an inlined definition and a definition
>         that exists in the keystore.";
>    }
>  }
>
> I was thinking if the 'leaf reference' in 'case keystore' should
> rather be 'mandatory true'. I know it does not make a difference
> now when there is only a single leaf in that case (and we don't
> plan more), but maybe it is more secure to have the mandatory flag
> on.

I guess it doesn't hurt but, assuming that there is no intention to
ever add more descendants to the "keystore" case, it's unnecessary
(as you say).  What is your concern?


> Regarding the groupings:
>
> I think the 'local' configurations in local-or-keystore groupings
> got too much capability in the end, and the locals became kind of
> full-fledged keystores. Shouldn't the local be simplified to binary
> privkey and certificate? I think local should be much simpler, but
> this is just my opinion. 

Below is the tree diagram for the "local" case from the
local-or-keystore-asymmetric-key-with-certs-grouping.  I picked
this grouping because it's the most complicated of them all.

   +--:(local) {local-keys-supported}?
      +-- algorithm?                       ct:key-algorithm-ref
      +-- public-key?                      binary
      +-- private-key?                     union
      +---x generate-hidden-key
      |  +---w input
      |     +---w algorithm                ct:key-algorithm-ref
      +---x install-hidden-key
      |  +---w input
      |     +---w algorithm                ct:key-algorithm-ref
      |     +---w public-key?              binary
      |     +---w private-key?             binary
      +-- certificates
      |  +-- certificate* [name]
      |     +-- name?                      string
      |     +-- cert?                      ct:end-entity-cert-cms
      |     +---n certificate-expiration
      |        +-- expiration-date?        yang:date-and-time
      +---x generate-certificate-signing-request
         +---w input
         |  +---w subject                  binary
         |  +---w attributes?              binary
         +--ro output
            +--ro certificate-signing-request    binary

I assume that you're having issue with the actions and perhaps 
also the notification.   Of course, these are due to the 
crypto-type groupings being used here.  As you've likely
noticed, the YANG modules aggressively use groupings.

Do you feel that "local" keys should never be "hidden"?  Why 
should keys used in keystore be the only ones that can be hidden?
What about devices that do not have the "keystore-supported"
feature, can they not have hidden keys? Assuming local keys
can be hidden, than the "generate-certificate-signing-request"
action is needed, right?  As for the notification, how is it 
not a good thing, even for "local" keys?


> This of course impacts what should be moved to ct. Some detailed
> thoughts below:
>
> 1. Is the 'local-or-keystore-asymmetric-key-with-certs-grouping'
> grouping used by any module? 

Not currently.  It was being used by the [ssh/tls]-client-server
modules, but I switched it out to the "local-or-keystore-end-entity-
certificate-grouping" because I think only a single certificate can
be specified in those cases.  Perhaps we should go back to using 
that grouping and have a "refine" statement to set "max-elements 1"?
This didn't occur to me before, but looking at it now, I think we 
should do it, and then remove local-or-keystore-asymmetric-key-with-
certs-grouping.

That said, I generally don't view unused groupings as a bad thing.
E.g., there are some unused groupings in crypto-types, though they
clearly seem like they could be useful in other contexts.   FWIW,
if we choose to keep the 2nd grouping, we should also add a "local-
or-keystore-trust-anchor-certificate-grouping", for symmetry.


> Client/server models seem to use only the ks:local-or-keystore-
> end-entity-certificate-grouping. Latter is lacking the action and
> cert is not in list. What was the objective with the local 
> configuration? Shouldn't it be much more simple than the keystore
> capability? Shouldn't it be just for configuring a non-hidden key
> and corresponding cert? Even the current local configuration with
> hidden key generate/install seem to be stepping on the toes of 
> keystore. Hidden key generation I guess would also need CSR 
> creation to bind the hidden key with a cert (which is not part
> of the local branches).

A lot of this I already touched on.  I do think local hidden keys
are a good thing.  As for the rest, I think you're making a case
for doing the alternative mentioned above (i.e., using a "refine"
statement to set "max-elements 1").


> 2. I guess crypto-types should contain the groupings that are
> foreseen to be reused. But those that we see only for keystore,
> could possibly remain in keystore. 'asymmetric-key-pair-with-certs'
> grouping contain way too much keystore specific implementation in
> my opinion, so it should be in keystore and not reused (unless 
> you really want to boost the capabilities of the 'local' 
> configuration). I would also keep 'end-entity-cert-grouping' in
> keystore with the certificate expiration information. 'trust-
> anchor-cert-grouping' could stay in trust anchors, it just adds
> a leaf. ' asymmetric-key-pair-grouping' should be in keystore IF
> it is only for keystore. Maybe if this latter was simpler that 
> the local configurations should also use, then that could be in ct.


The above covers all this but, to provide insight, know that I moved
all groupings that were NOT keystore specific.  That they're somehow
overly robust was not a factor in that decision making process.  Yes,
I do want to "boost" local keys, per my comments above.
 
I was about to write that, if we remove "ks:local-or-keystore-end-
entity-certificate-grouping", we could remove "ct:end-entity-cert-
grouping", but then notice that "ct:asymmetric-key-pair-with-certs-
grouping" is using it too.  Hmmm....

I presume that you're not picking on ct:trust-anchor-cert-grouping
only because it doesn't define a notification, but know that I went
back and forth on that, and I think I made a mistake.  I now think
that it should define a notification and that the trust-anchors 
draft should move to using it, with a refine statement setting 
"max-elements 1".

Regards,
Kent