Return-Path: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63937120831 for ; Wed, 13 Nov 2019 14:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_uVf0Z43J4M for ; Wed, 13 Nov 2019 14:02:06 -0800 (PST) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F4098120830 for ; Wed, 13 Nov 2019 14:02:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1573682524; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=vRTb6tGl/I4fWhfzTJ1BPbm2hXnpXxFvpwz+J9Txjf8=; b=QO0ZWzb3v1fABq49C7sShXdfDxdJ6PDxiM/kgzXkR+1yFBKaIyg4L2yU9RvcYA1T CZRAs39qkZuE90GqTcoLbcdUwUFarvUSPmN5yNgkGIdbbLEioT/6wddZScpVG9kooxc Hir1hzCN5o20PvAC1eVA+gXPaWGvwj7ZGM4WXGaU= From: Kent Watsen Message-ID: <0100016e66c9b02d-382d9d6e-6d88-47ec-a117-5f38a3699fb1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 13 Nov 2019 22:02:04 +0000 In-Reply-To: <20191113.135649.2218807015240802033.mbj@tail-f.com> Cc: "netconf@ietf.org" , Wang Haiguang To: Martin Bjorklund References: <20191113.135649.2218807015240802033.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.11.13-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types and keystore comments X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 22:02:10 -0000 --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > o Is the key-format there to support multiple formats for the same > kind of key (e.g., ssh key), or is it there to be able to have > different kinds of keys in the same list? (Or both?) >=20 > I.e., is the intentation that a client can freely pick any > private-key-format (that is supported by the server), regardless of > how the key is used? Firstly, see: = https://mailarchive.ietf.org/arch/msg/netconf/5Zpj8Xxh7bHvAJeQf2Lj0t6h8hg = That said, there are some limitations that are likely not represented = yet. For instance, an encrypted private key must use "identity = encrypted-private-key-format" and an encrypted symmetric key must use = "identity encrypted-symmetric-key-format", as there is no way to express = it otherwise. But your question is likely more regarding the other direction, for an = *unencrypted" asymmetric key, can a client arbitrarily choose one of the = *-private-key-format identities or "identity one-asymmetric-key-format"; = likewise, for an *unencrypted* symmetric key, can a client arbitrarily = use either "identity octet-string-key-format" or "identity = one-symmetric-key-format". The goal is for the use of OneAsymmetricKey and OneSymmetricKey formats = to be an advanced feature. As said above, these structures must be used = for encrypted keys, and should be used for unencrypted key (as the = structure carries security attributes not present in the raw formats), = but it's more likely that implementations will support the raw formats. My thoughts are that, if an implementation is updated to support for = One[A]SymmetricKey for encrypted keys, then letting a client optionally = use One[A]SymmetricKey for unencrypted keys isn't that big of an = implementation effort. Thus I suggest adding features called = "one-symmetric-key" and "one-asymmetric-key", and place if-feature = statements under these identities so that servers can express when they = support them. > o One idea that was floating around was to have separate keystore > lists for different things (see the ML archives, e.g. some mails in > the thread "crypto-types fallback strategy"). I.e. instead of the > current: >=20 > +--rw keystore > +--rw asymmetric-keys > | +--rw asymmetric-key* [name] >=20 >=20 > we would have something like: >=20 > +--rw keystores > +--rw ssh-keystore > | ... > +--rw tls-keystore // x509-keystore? > ... Right, but that approach was deemed not viable before. > If we don't have to support multiple formats for the same kind > of key, I don't think we need the key-format in this case. Maybe. > With the current design it is not obvious to me how I can find all > ssh keys, for example. That's because keys don't have to have a set purpose. For instance, an = IDevID shipped with the device could be used for either SSH or TLS. > This said, *if* we use a single generic list, I think the list in > the current model works fine. It is a bit complicated, but some > complexity is inevitable with a generic model like this. Yes and yes. > o iana- modules >=20 > The iana modules have a list of supported algorithms, e.g.: >=20 > list supported-asymmetric-algorithm >=20 > I mentioned this before - I don't think a global list like this is > sufficient. For example, perhaps my TLS code supports "secp521r1", > but my SSH code does not. Yes, well, this is a known problem (e.g., = https://github.com/netmod-wg/yang-next/issues/82 = ). I realize that = you're not specifically talking about feature statements, but it's = similar. One difference between #82 and this is that here, the = capabilities are presented in "config false" lists instead, which might = bring us to https://github.com/netmod-wg/yang-next/issues/41 = again... > And some random small things I noticed: >=20 > o ssh-public-key-format >=20 > The crypto model has: >=20 > identity ssh-public-key-formatp { > base "public-key-format"; > description > "The public key format described by RFC 4716."; > } >=20 > I think that this should be: >=20 > description > "The binary public key data for an SSH key, as > specified by RFC 4253, Section 6.6, i.e.: >=20 > string certificate or public key format > identifier > byte[n] key/certificate data."; > reference > "RFC 4253: The Secure Shell (SSH) Transport Layer > Protocol"; >=20 > Note that the public key format in 4716 is textual: >=20 > ---- BEGIN SSH2 PUBLIC KEY ---- > Header-tag ':' ' ' Header-value > BODY > ---- END SSH2 PUBLIC KEY ---- >=20 > Where BODY is: >=20 > The body of a public key file is the base64 encoded ([RFC2045]) > public key data as specified by [RFC4253], Section 6.6: >=20 > string certificate or public key format identifier > byte[n] key/certificate data >=20 > So with your current definition we would take this textual format > (that has the key base64-encoded), and base64 encode the whole > thing (includign the already base64-encoded key). I will say that the definition above was given because it is the only = *standards* based key that `openssh` can output (i.e., `ssh-keygen -e = [-m RFC4716] -f `). That said, if you refer to the link I provided at top, it is my belief = that the "key-format" node may be extended to support alternate = encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM). = To this end, perhaps we could support both the 4716 and 4253 formats.=20 > o subject-public-key-info-format >=20 > The crypto model has: >=20 > identity subject-public-key-info-format { > base "public-key-format"; > description > "A SubjectPublicKeyInfo (from RFC 5280)."; > } >=20 > Should this be "DER encoded"? >=20 > (this and other defintions have references to RFCs in the > description; they should be moved to proper "reference" statements) Yes. I put together these definitions in as a test/protocol to gauge = viability with the plan to enhance the definitions if the WG committed = to the approach. I just added some "FIXME" comments to my local copy. > o iana-hash-algs >=20 > This module has a bunch of shake-*: >=20 > enum shake-224 { > value 7; > description > "The SHA3 algorithm with 224-bits output."; >=20 > I think this should be "sha3-224" etc. >=20 > (there are just two shake hash functions defined; shake 128 & 256, > and they have variable output) >=20 > (and BTW, FIPS PUB 202 doesn't define sha3-128) I don't know. These are are/were specified by my co-author Haiguang = (CC-ed). Haiguang, can you comment? Kent // contributor --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


Hi = Martin,


o  Is the = key-format there to support multiple formats for the same
=   kind of key (e.g., ssh key), or is it there to be able to = have
  different kinds of keys in the same = list?  (Or both?)

  I.e., = is the intentation that a client can freely pick any
=   private-key-format (that is supported by the server), = regardless of
  how the key is used?


That said, there = are some limitations that are likely not represented yet.  For = instance, an encrypted private key must use = "identity encrypted-private-key-format" and an encrypted symmetric = key must use "identity encrypted-symmetric-key-format", as there is = no way to express it otherwise.

But = your question is likely more regarding the other direction, for an = *unencrypted" asymmetric key, can a client arbitrarily choose one of the = *-private-key-format identities or = "identity one-asymmetric-key-format"; likewise, for an = *unencrypted* symmetric key, can a client arbitrarily use either = "identity octet-string-key-format" or "identity = one-symmetric-key-format".

The goal = is for the use of OneAsymmetricKey and OneSymmetricKey formats = to be an advanced feature.  As said above, these structures must be = used for encrypted keys, and should be used for unencrypted key (as the = structure carries security attributes not present in the raw formats), = but it's more likely that implementations will support the raw = formats.

My thoughts are that, if an = implementation is updated to support for One[A]SymmetricKey for = encrypted keys, then letting a client optionally use One[A]SymmetricKey = for unencrypted keys isn't that big of an implementation effort. =  Thus I suggest adding features called "one-symmetric-key" and = "one-asymmetric-key", and place if-feature statements under these = identities so that servers can express when they support = them.


o  One = idea that was floating around was to have separate keystore
=   lists for different things (see the ML archives, e.g. some = mails in
  the thread "crypto-types fallback = strategy").  I.e. instead of the
=   current:

  +--rw = keystore
     +--rw = asymmetric-keys
     | =  +--rw asymmetric-key* [name]


  we would have something like:

  +--rw keystores
=      +--rw ssh-keystore
=      |  ...
=      +--rw tls-keystore  // = x509-keystore?
=         ...

Right, = but that approach was deemed not viable before.


  If we don't have to support = multiple formats for the same kind
  of key, I = don't think we need the key-format in this = case.

Maybe.


  With the current design it is not obvious to me how I = can find all
  ssh keys, for example.

That's = because keys don't have to have a set purpose.  For instance, an = IDevID shipped with the device could be used for either SSH or = TLS.


  This = said, *if* we use a single generic list, I think the list in
  the current model works fine.  It is a bit = complicated, but some
  complexity is = inevitable with a generic model like this.

Yes = and yes.



o   iana- modules

 The iana modules have a list of supported algorithms, = e.g.:

=       list = supported-asymmetric-algorithm

 I = mentioned this before - I don't think a global list like this is
 sufficient.  For example, perhaps my TLS code = supports "secp521r1",
 but my SSH code does not.

Yes, = well, this is a known problem (e.g., https://github.com/netmod-wg/yang-next/issues/82). =  I realize that you're not specifically talking about feature = statements, but it's similar.  One difference between #82 and this = is that here, the capabilities are presented in "config false" lists = instead, which might bring us to https://github.com/netmod-wg/yang-next/issues/41 again= ...



And some random small things I noticed:

o  ssh-public-key-format

=  The crypto model has:

=    identity ssh-public-key-formatp {
=      base "public-key-format";
=      description
=        "The public key format = described by RFC 4716.";
   }

 I think that this should be:

   description
=      "The binary public key data for an SSH = key, as
      specified by = RFC 4253, Section 6.6, i.e.:

=         string =    certificate or public key format
=             &n= bsp;     identifier
=         byte[n] =   key/certificate data.";
=    reference
=      "RFC 4253: The Secure Shell (SSH) = Transport Layer
=             &n= bsp;   Protocol";

=  Note that the public key format in 4716 is textual:

   ---- BEGIN SSH2 PUBLIC KEY = ----
   Header-tag ':' ' ' Header-value
   BODY
   ---- = END SSH2 PUBLIC KEY ----

 Where BODY = is:

  The body of a public key = file is the base64 encoded ([RFC2045])
  public = key data as specified by [RFC4253], Section 6.6:

        string =    certificate or public key format identifier
        byte[n] =   key/certificate data

 So = with your current definition we would take this textual format
 (that has the key base64-encoded), and base64 encode = the whole
 thing (includign the already = base64-encoded key).

I will say that the definition above was given = because it is the only *standards* based key that `openssh` can output = (i.e., `ssh-keygen -e [-m RFC4716] -f = <private-key-file>`).

That = said, if you refer to the link I provided at top, it is my belief that = the "key-format" node may be extended to support alternate encodings = (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).  To = this end, perhaps we could support both the 4716 and 4253 = formats. 



o =  subject-public-key-info-format

=  The crypto model has:

=    identity subject-public-key-info-format {
=      base "public-key-format";
=      description
=        "A SubjectPublicKeyInfo (from = RFC 5280).";
   }

 Should this be "DER encoded"?

 (this and other defintions have references to RFCs in = the
 description; they should be moved to proper = "reference" statements)

Yes.  I put together these definitions in as = a test/protocol to gauge viability with the plan to enhance the = definitions if the WG committed to the approach.   I just added = some "FIXME" comments to my local copy.



o  iana-hash-algs

=  This module has a bunch of shake-*:

=      enum shake-224 {
=        value 7;
=        description
=          "The SHA3 = algorithm with 224-bits output.";

 I = think this should be "sha3-224" etc.

=  (there are just two shake hash functions defined; shake 128 & = 256,
 and they have variable output)
 (and BTW, FIPS PUB 202 doesn't define sha3-128)

I = don't know.  These are are/were specified by my co-author Haiguang = (CC-ed).   Haiguang, can you comment?


Kent // contributor


= --Apple-Mail=_63F7BFFB-920C-4349-BFCE-C5C9A87BD47B--