Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

[CC-ing Henk, who lobbied for adding PSK and raw public keys to the trust store draft]


> >If I am not wrong, TLS 1.3 support to use raw public key between client and server.
> I think TLS + Raw public key has been specified in RFC 7250 and later merge in RFC 8446 (TLS 1.3)
>  
> You are not wrong.  But public keys do not need to be encrypted or protected by other privacy means.  Private keys still do.  So “TLS with raw keys” does not change the security requirements compared to “TLS with certificates.”
>  
> My issue is that I do not think “TLS with raw keys” is used very much, and we do not have to support it in the first versions of these documents.

I'd like to get Henk's opinion on this.   

Henk, we're talking about modifying the tls-client-server draft to reference all private-key types in Keystore. Specifically, a PSK is effectively a /keystore:asymmetric-keys/asymmetric-key, and a raw public-key is effectively a /keystore:symmetric-keys/symmetric-key, right?  So the question is, when requesting the ability to authenticate TLS servers using those mechanisms, is there also a need to configure the private keys?


All, looking at ietf-tls-client.yang and ietf-tls-server.yang, adding the ability to configure the "private" half of a PSK or raw public key would be something like:

	OLD
	    container <client-identity or server-identity> {
	      uses ks:local-or-keystore-end-entity-cert-with-key-grouping;

	NEW
	    container <client-identity or server-identity> {
	      choice auth-type {
	         uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
	         uses ks:local-or-keystore-raw-public-key-grouping;
	         uses ks:local-or-keystore-pre-shared-key-grouping;

Kent