Subject: Re: [Netconf] netconf server-model (keychain) draft issues

From: Sean Turner <[email-masked]>
Date: Thu, 30 Jun 2016 18:01:21 -0400

Sorry for completely dropping the ball on this.  Hopefully, I can redeem myself here.

> On May 11, 2016, at 15:19, Kent Watsen <[email-masked]> wrote:
> 
> Hi Sean,
> 
> Thank you again for your review of the server-model draft before, primarily focusing on the keychain model.  As you know, I updated the draft significantly based on your comments for 95, but one issue remains... 
> 
> The remaining issue regards 'key-usage' in the generate-private-key action listed on page 23 of https://tools.ietf.org/html/draft-ietf-netconf-server-model-09.  Below is the current (incomplete) definition:
> 
>           leaf key-usage {
>             type enumeration {
>               enum signing    { description "signing"; }
>               enum encryption { description "encryption"; }
>               // unclear if these should be somehow more
>               // specific or varied.
>             }
> 
> The question is how to make this key-usage definition complete?  I can do the YANG translation, but what are the possible values?  Is it the case that the issue only matters when discussing TPMs, which have very distinct and specific usage profiles?   As a generic keychain model, it shouldn't be specific to network management, but it would be remiss for me to not point out that, in network management, the private key seems to always have the same key usage (i.e. what's needed to establish a SSH/TLS tunnel).   Thoughts?
> 
> Thanks,
> Kent

As far as completeness goes, it’s going to be hard because one of the fields defined to carry key usage in the certificate is open ended.  As far as background goes there’s two key usage fields in a cert and they both in extensions:

0. Key Usage can be found in s4.2.1.3 of RFC 5280.  It lists some usages that the ITU/IETF folks thought were useful (apologies for the ASN.1):

KeyUsage ::= BIT STRING {
  digitalSignature  (0),
  nonRepudiation  (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
  keyEncipherment         (2),
  dataEncipherment        (3),
  keyAgreement            (4),
  keyCertSign             (5),
  cRLSign                 (6),
  encipherOnly            (7),
  decipherOnly            (8) }

1. And because that list isn’t all encompassing they also defined an Extended Key Usages extension which is essentially a sequence of OIDs.  A bunch have been defined here:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3
Because anybody can get an OID, anybody can define a key usage so that list isn’t all encompassing.

As far as what people use, most TLS certificates include both id-kp-serverAuth and id-kp-clientAuth.  I’ll need to go dig up what ssh-based certificates use.  Does this at least answer some of it?

spt