Re: [Netconf] Mandatory local configuration in Keystore groupings

[Balázs Kovács <[e-mail]>]

Hi Kent,

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.

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. This of course impacts what should be moved to ct. Some detailed thoughts below:

1. Is the 'grouping local-or-keystore-asymmetric-key-with-certs-grouping' grouping used by any module? 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).

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.

Br,
Balazs


-----Original Message-----
From: Kent Watsen <[e-mail]> 
Sent: Wednesday, October 10, 2018 4:48 AM
To: Balázs Kovács <[e-mail]>; Martin Bjorklund <[e-mail]>
Cc: [e-mail]
Subject: Re: [Netconf] Mandatory local configuration in Keystore groupings

Hi Balazs,

Answering both of your messages here.


> I was checking it at the moment and noticed something that may be a miss.
>
>  typedef asymmetric-key-ref {
>    type leafref {
>      path "/ks:keystore/ks:asymmetric-keys/ks:asymmetric-key"
>           + "/ks:name";
>      require-instance false;
>    }
>    description
>      "This typedef enables modules to easily define a reference
>       to an asymmetric key stored in the keystore. The require
>       instance attribute is false to enable the referencing of
>       asymmetric keys that exist only in <operational>.";
>    reference
>      "RFC 8342: Network Management Datastore Architecture (NMDA)";  }
>
> I think we were discussing changing 'require-instance' to 'true' 
> in relation to the change toward alternative (C) as discussed below. 
> Should it be 'true' instead of 'false'?

Yes.  I removed the "require-instance" statement, and fixed the "description" statement in my local copy.  New description
statement:

      "This typedef enables modules to easily define a reference 
       to an asymmetric key stored in the keystore.";

I did the same for the asymmetric-key-certificate-ref typedef, as we should apply the same (C) trick there as well.  But doing this required removing the "mandatory true" from end-entity-cert-grouping.
For full measure, I also removed the "mandatory true" from the trust-anchor-cert-grouping, as that seemed to be the same issue as the others.


> One more question. I found this in ct:
>
>  grouping asymmetric-key-pair-with-certs-grouping {
>    description
>      "A private/public key pair and associated certificates.";
>    uses asymmetric-key-pair-grouping;
>    container certificates {
>      description
>        "Certificates associated with this asymmetric key.
>         More than one certificate supports, for instance,
>         a TPM-protected asymmetric key that has both IDevID
>         and LDevID certificates associated.";
>      list certificate {
>        must "../../algorithm
>               and ../../public-key
>                 and ../../private-key";
>        key name;
>        description
> ...
>
> Is it ok to have the must statement in the certificate list? 
> I think with (C) the idea was to have hidden keys represented in the 
> configuration for which certificates can still be configured, but 
> hidden keys will have no algorithm/public-key\ /private-key in 
> configuration. What's your view?

Yes.  I removed the "must" statement in my local copy and changed the description statement for /keystore/asymmetric-keys/asymmetric-key/name
as follows:

OLD:
            "An arbitrary name for the asymmetric key.";
NEW:
            "An arbitrary name for the asymmetric key.  If the name
             matches the name of a key that exists independently in
             <operational> (i.e., a 'permanently-hidden' key), then
             the 'algorithm', 'public-key', and 'private-key' nodes
             MUST NOT be configured.";

As well the description statement for asymmetric-key-pair-with-
certs-grouping/certificates/certificate/name:

OLD:
            "An arbitrary name for the certificate.";
NEW:
            "An arbitrary name for the certificate.  If the name
             matches the name of a certificate that exists
             independently in <operational> (i.e., an IDevID), 
             then the 'cert' node MUST NOT be configured.";



BTW, you probably noticed this comment in keystore:

  // MOVED TO CRYPTO TYPES DRAFT? - OKAY TO REMOVE HERE NOW?
  // <snip/>

Any thoughts about that move? - better?



Thanks,
Kent