Subject: [netconf] Regarding today's updates

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Jul 2020 01:39:16 +0000

TR;DL;  

    - first 3 WGLC drafts updated per comments received
        - please review to ensure your comments were addressed!

    - remaining drafts 99% WGLC-ready 
        - just a few niggles left  ;)

K.

crypto-types

   *  Updated draft title (refer to "Groupings" too).

   *  Removed 'end-entity-certs-grouping' as it wasn't being used
      anywhere.

   *  Removed 'trust-anchor-certs-grouping' as it was no longer being
      used after modifying 'local-or-truststore-certs-grouping' to use
      lists (not leaf-lists).

   *  Renamed "cert" to "cert-data" in trust-anchor-cert-grouping.

   *  Added "csr-info" typedef, to complement the existing "csr"
      typedef.

   *  Added "ocsp-request" and "ocsp-response" typedefs, to complement
      the existing "crl" typedef.

   *  Added "encrypted" cases to both symmetric-key-grouping and
      asymmetric-key-pair-grouping (Moved from Keystore draft).

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

truststore

   *  Corrected module prefix registered in the IANA Considerations
      section.

   *  Modified 'local-or-truststore-certs-grouping' to use a list (not a
      leaf-list).

   *  Added new example section "The Local or Truststore Groupings".

   *  Clarified expected behavior for "built-in" certificates in
      <operational>

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

keystore

   *  Removed dangling/unnecessary ref to RFC 8342.

   *  r/MUST/SHOULD/ wrt strength of keys being configured over
      transports.  [UPDATE: oops, I think I deleted it altogether later]

   *  Added an example for the "certificate-expiration" notification.

   *  Clarified that OS MAY have a multiplicity of underlying keystores
      and/or HSMs.

   *  Clarified expected behavior for "built-in" keys in <operational>

   *  Clarified the "Migrating Configuration to Another Server" section.

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

tcp-client-server

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

ssh-client-server

   *  Added a "must 'public-key or password or hostbased or none or
      certificate'" statement to the "user" node in ietf-ssh-client

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Moved the "ietf-ssh-common" module section to proceed the other
      two module sections.

   *  Updated the Security Considerations section.

tls-client-server

   *  Modified the 'must' expression in the "ietf-tls-client:server-
      authention" node to cover the "raw-public-keys" and "psks" nodes
      also.

   *  Added a "must 'ca-certs or ee-certs or raw-public-keys or psks'"
      statement to the ietf-tls-server:client-authentication" node.

   *  Added "mandatory true" to "choice auth-type" and a "presence"
      statement to its ancestor.

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Moved the "ietf-ssh-common" module section to proceed the other
      two module sections.

   *  Updated the Security Considerations section.

http-client-server

   *  Added a parent "container" to "client-identity-grouping" so that
      it could be better used by the proxy model.

   *  Added a "choice" to the proxy model enabling selection of proxy
      types.

   *  Added 'http-client-stack-grouping' and 'http-server-stack-
      grouping' convenience groupings.

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

netconf-client-server

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Removed expanded tree diagrams that were listed in the Appendix.

   *  Updated the Security Considerations section.

restconf-client-server

   *  Moved and changed "must" statement so that either TLS *or* HTTP
      auth must be configured.

   *  Expanded "Data Model Overview section(s) [remove "wall" of tree
      diagrams].

   *  Updated the Security Considerations section.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Jul 2020 14:11:09 +0000

Question:

In the crypto-types draft, the symmetric and asymmetric key definitions each support three encodings for the secret key-data: cleartext, hidden, and encrypted.  To see this, here are direct links to the tree diagrams:

    - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.2 <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.2>
    - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.4 <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.4>

My question is, should the “key” and “private-key” nodes be renamed to “cleartext-key” and “cleartext-private-key”?

    PROs:
        - a positive assertion the key is in the clear is more secure

    CONs:
        - a longer name for the most common case

Thoughts?

PS: I’m aware that the truststore draft’s "Data at Rest” Security Consideration section has a copy/paste error in it, which I’ll update that before the cutoff...

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Jul 2020 16:27:15 +0200

On Thu, Jul 09, 2020 at 02:11:09PM +0000, Kent Watsen wrote:
>     - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1..4.2 <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.2>
>     - https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1..4.4 <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.1.4.4>
> 

I think longer names are a good thing here since the longer name may
also serve as a warning.

Perhaps raw-key (hidden-key, encrypted-key) and raw-private-key
(hidden-private-key, encrypted-private-key) if you want shorter names?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 9 Jul 2020 14:43:27 +0000

> I think longer names are a good thing here since the longer name may

Exactly.

> (hidden-private-key, encrypted-private-key) if you want shorter names?

“Raw” is not a bad option.   Semantically, the difference to “cleartext” seems very small.   Length isn’t a huge-issue either, being a programmatic API.  Maybe one is preferred from a historical-use perspective?  (Rich, maybe you can comment here?)

Here’s a couple relevant snippets from https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.2.1: <https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-16#section-2.2.1:>

     <symmetric-key>
       <name>ex-octet-string-based-symmetric-key</name>
       <key-format>ct:octet-string-key-format</key-format>
       <key>base64encodedvalue==</key>
     </symmetric-key>

     <asymmetric-key>
       <name>ex-subject-public-info-based-asymmetric-key</name>
       <public-key-format>
         ct:subject-public-key-info-format
       </public-key-format>
       <public-key>base64encodedvalue==</public-key>
       <private-key-format>
         ct:rsa-private-key-format
       </private-key-format>
       <private-key>base64encodedvalue==</private-key>
       <certificates>
         <certificate>
           <name>ex-cert</name>
           <cert-data>base64encodedvalue==</cert-data>
         </certificate>
       </certificates>
     </asymmetric-key>

The name is not visually prevalent in context --> any prefix would be fine...

K.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Jul 2020 14:50:06 +0000

*   “Raw” is not a bad option.   Semantically, the difference to “cleartext” seems very small.   Length isn’t a huge-issue either, being a programmatic API.  Maybe one is preferred from a historical-use perspective?  (Rich, maybe you can comment here?)

I think informed folks won’t care about raw/cleartext.  But I think newer folks will appreciate “cleartext” better.  FWIW, to me a “raw” key is one that stands alone, as opposed to a public key embedded in an X509 certificate.

HTH.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 10 Jul 2020 20:02:45 +0000

Minor updates (not all drafts updated)

   crypto-types:
       *  [Re]-added a "Strength of Keys Configured" Security Consideration
       *  Prefixed "cleartext-" in the "key" and "private-key" node names.

   trust-anchors:
       *  Fixed a copy/paste issue in the "Data at Rest" Security
          Considerations section.

   keystore + ssh-client-server + tls-client-server:
       *  Updated examples to reflect new "cleartext-" prefix in the
          crypto-types draft.

K.

> On Jul 8, 2020, at 9:39 PM, Kent Watsen <[email-masked]> wrote:
> 
> TR;DL;  
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf