Subject: [netconf] truststore usage in ietf-ssh/tls-client/server

From: Balázs Kovács <[email-masked]>
Date: Fri, 4 Oct 2019 11:56:46 +0000

Hi Kent,

Can you confirm that in the ietf-tls-client and ietf-tls-server models the direct use of truststore references in server-authentication and client-authentication containers will change to using local-or-truststore-certs-grouping?

Similarly in ssh models, will they change to local-or-truststore-host-keys-grouping?

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Mon, 7 Oct 2019 17:48:05 +0000

Hi Balazs,

> Similarly in ssh models, will they change to local-or-truststore-host-keys-grouping?

Yes, it would make sense to use those groupings.

I just committed the following updates:

   SSH: https://github.com/netconf-wg/ssh-client-server/commit/5292d87ef47aafd2475241f82e76d8ac11defd11 <https://github.com/netconf-wg/ssh-client-server/commit/5292d87ef47aafd2475241f82e76d8ac11defd11>
    TLS: https://github.com/netconf-wg/tls-client-server/commit/d7b8c81bbd2dbbe5812e5519e4129abaf8012eb1 <https://github.com/netconf-wg/tls-client-server/commit/d7b8c81bbd2dbbe5812e5519e4129abaf8012eb1>

What do you think?  All good?

Kent  // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 8 Oct 2019 19:38:32 +0000

Hi Kent,

   SSH: https://github.com/netconf-wg/ssh-client-server/commit/5292d87ef47aafd2475241f82e76d8ac11defd11<https://protect2.fireeye.com/url?k=190005f0-458acf33-1900456b-86e1ed4002b1-2bf47647e54d6cab&q=1&u=https%3A%2F%2Fgithub.com%2Fnetconf-wg%2Fssh-client-server%2Fcommit%2F5292d87ef47aafd2475241f82e76d8ac11defd11>
    TLS: https://github.com/netconf-wg/tls-client-server/commit/d7b8c81bbd2dbbe5812e5519e4129abaf8012eb1<https://protect2.fireeye.com/url?k=70df6aa5-2c55a066-70df2a3e-86e1ed4002b1-d8431043a52ea433&q=1&u=https%3A%2F%2Fgithub.com%2Fnetconf-wg%2Ftls-client-server%2Fcommit%2Fd7b8c81bbd2dbbe5812e5519e4129abaf8012eb1>

1.

In ssh-client and ssh-server:

"Indicates that the client can authenticate servers
using the configured trust anchor certificates.";

"Indicates that the server can authenticate this user
using the configured trust anchor certificates.";

Do you prefer 'trust anchor' or could it be changed to 'certificate authority'?

2.

What's the rationale of the new presence containers in ssh models but not in the tls models?

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Tue, 8 Oct 2019 20:56:02 +0000

Hi Balazs,

> Do you prefer ‘trust anchor’ or could it be changed to ‘certificate authority’?

Good question.  I was cognizant of the fact the the surrounding nodes and text uses CA (e.g., ca-certs).  But crypto-types uses the term "trust-anchor" (in contrast to "end-entity"), which seems more exact.  I was half-thinking to swap "ca-cert" for "trust-anchor" everywhere in the SSH and TLS models.  I think the result would be more consistent, but haven't looked carefully.  Thoughts?

>  2.
>                                                                        
> What’s the rationale of the new presence containers in ssh models but not in the tls models?

Good catch.  The examples didn't test this "case" and hence the issue was missed.  I added this to the TLS models here: https://github.com/netconf-wg/tls-client-server/commit/0eb86e7c9644cc396de7ab49037ed9ea40d5a75b <https://github.com/netconf-wg/tls-client-server/commit/0eb86e7c9644cc396de7ab49037ed9ea40d5a75b>.

FWIW, ts:local-or-truststore-certs-grouping contains a mandatory choice that was forcing the nodes to be defined all the time...

Kent // contributor

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 8 Oct 2019 21:00:53 +0000

The “trust anchor” is the rootmost CA in a chain of certificates.

(RATS/EAT has other definitions of the term, but for X509 certificates and TLS configuration, this correct.)

I think this means that you should use the term “CA”

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 9 Oct 2019 06:52:18 +0000

Hi,

I’m also rather in favor of ca-certs, especially if “trust anchor” means the root CA. Also in development the term CA certificate is much more understandable. I think the type allows a CA chain or one could use these leaves for partial chain validation too.

Regarding the presence containers, if local-or-truststore-* have mandatory choice then I think you need to make the local-or-keystore-* containers also presence.

Br,
Balazs

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 9 Oct 2019 07:03:35 +0000

Hi,

it may help to adopt terminology defined in RFC 4949. RFC 4949 for
example says:

   $ trust anchor certificate
      (I) A public-key certificate that is used to provide the first
      public key in a certification path. (See: root certificate, trust
      anchor, trusted certificate.)

/js

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
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: Henk Birkholz <[email-masked]>
Date: Wed, 9 Oct 2019 09:23:56 +0200

Hi Balazs,

RATS tries to avoid using the concept TA actually.

In any case, if used/spoken of, it is the definition of RFC4949.

Rephrasing that: An entity outside the device, that you can put trust 
into (or not) that provides you with a pub-key root certificate 
associated via a certification path with other certificates that are 
presented to you.

In RATS they are used, for example, to be able to trust endorsement 
certificates about sub-components in a composite device (the things you 
cannot create attestation evidence for, such as roots of trusts).

Viele Grüße,

Henk

On 09.10.19 08:52, Balázs Kovács wrote:
> I’m also rather in favor of ca-certs, especially if “trust anchor” means 
> the root CA. Also in development the term CA certificate is much more 
> understandable. I think the type allows a CA chain or one could use 
> these leaves for partial chain validation too.
> 
> Regarding the presence containers, if local-or-truststore-* have 
> mandatory choice then I think you need to make the local-or-keystore-* 
> containers also presence.
> 
> Br,
> 
> Balazs
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Oct 2019 14:56:21 +0000

Hi Balazs,

> I’m also rather in favor of ca-certs, especially if “trust anchor” means the root CA. Also in development the term CA certificate is much more understandable. I think the type allows a CA chain or…

Noted.

>  Regarding the presence containers, if local-or-truststore-* have mandatory choice then I think you need to make the local-or-keystore-* containers also presence.

I just looked and all seems proper.  The local-or-keystore-* containers are required, as they hold or reference the obligatory private key.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Oct 2019 15:49:06 +0000

[changing the subject line]

> it may help to adopt terminology defined in RFC 4949.

Indeed, but let's start this inquisition with crypto-types:

	$ grep trust-anchor ietf-crypto-types.yang

	  typedef trust-anchor-cert-x509 {
	  typedef trust-anchor-cert-cms {
	  grouping trust-anchor-cert-grouping {
	      type trust-anchor-cert-cms;
	  grouping trust-anchor-certs-grouping {
	      type trust-anchor-cert-cms;

But also note:

	$ grep end-entity ietf-crypto-types.yang 

	  typedef end-entity-cert-x509 {
	  typedef end-entity-cert-cms {
	  grouping end-entity-cert-grouping {
	      type end-entity-cert-cms;
	  grouping end-entity-certs-grouping {
	      type end-entity-cert-cms;
	    uses end-entity-cert-grouping;
	        uses end-entity-cert-grouping;

Note in particular the "cms" types, as they hold a partial sequence of certificates.  The "trust-anchor" sequence always leads to a root certificate.  The "end-entity" sequence always leads to a "CA False" certificate.  These types are meaningfully used in the client/server suite of drafts.  For instance, a TLS server can present a partial end-entity certificate chain which the client stitches into a partial trust-anchor certificate chain.  It is important to support partial chains for operational reasons, not to mention a number of crypto libraries don't support partial certificate path validation.

In RFC 4949, "certification path" or "trust chain" or "trusted CA" seem close.

Kent // contributor