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

From: Kent Watsen <[email-masked]>
Date: Fri, 1 Jul 2016 15:42:52 +0000

Hi Sean,

Thank you for your response - it’s never too late!   ;)

I think you may be mixing up certs-generation and key-generation.   In https://tools.ietf.org/html/draft-ietf-netconf-server-model-09#section-4.1.1, key-usage is being used as an input parameter for the 'generate-private-key' command:

         +---x generate-private-key
            +---w input
               +---w name          string
               +---w key-usage?    enumeration
               +---w algorithm     kc:algorithms
               +---w key-length?   uint32

The idea being that system will somehow remember why the key was created.  For instance, this might be important when asking a TPM to generate the key.

Separately, the keychain model has a configuration node to associate certificates with a private-key and, when these certs are generated, I would expect that their KeyUsage value would be set correctly for their anticipated use:

      +--rw private-keys
          +--rw private-key* [name]
             +--rw name                                    string
             +--ro algorithm?                              kc:algorithms
             +--ro key-length?                             uint32
             +--ro public-key                              binary
             +--rw certificate-chains
                +--rw certificate-chain* [name]
                   +--rw name           string
                   +--rw certificate*   binary

As I understand it, the private key itself is typically (TPMs withstanding) created without awareness of how it might be used.   In general, I’d think that our “key-usage” input parameter would not be set, telling the system to generate a generic key.   If we remove support for generating private keys within a TPM from this draft, I might think to remove the “key-usage” input parameter entirely.   

What do you think?

Thanks,
Kent

On 6/30/16, 6:01 PM, "Sean Turner" <[email-masked]> wrote:

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 1 Jul 2016 13:17:49 -0400

Ah yep you’re right I’m conflating cert-gen and key-gen.  When you do a key-gen in say openssl you’re say give me key pair with these parameters (algorithm, key size, curve, etc.).  You might give it more parameters for one of the “combo” commands (e.g., generate self-signed certificate), but then you’re just combining multiple steps sequentially and the key-gen step is still just make key pair with these parameters.

Also, because private keys aren’t normally exchanged there’s not a lot of standardization wrt to ways to indicate private key usages/purpose.  There are some, but I categorize them as exotic.

Finally, if you’ve organized the private and public keys so that they’re related (maybe both are subordinate to the same parent node/object) then you’ll get the key usages from the public key.  This is kind of like when you store the private and public key in a PKCS#8, both keys are together and you can figure out what the private key should be used for based on the public key algorithm, key usages, etc.

Hope this helps.

spt

> On Jul 01, 2016, at 11:42, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Sean,
>