Re: [netconf] FIXMEs in ietf-crypto-types and client/server models

Henk Birkholz <> Wed, 06 November 2019 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8071A120BFF for <>; Tue, 5 Nov 2019 23:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z0PCRD6yFH0r for <>; Tue, 5 Nov 2019 23:56:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 037F7120C01 for <>; Tue, 5 Nov 2019 23:56:11 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xA67u7fB015319 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 6 Nov 2019 08:56:08 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 6 Nov 2019 08:56:02 +0100
To: Kent Watsen <>, =?UTF-8?B?QmFsw6F6cyBLb3bDoWNz?= <>
CC: "" <>
References: <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Wed, 6 Nov 2019 08:56:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models
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, 06 Nov 2019 07:56:16 -0000

Hi Balázs,
hi list,

Item 3.) is on me, I think. Sorry!

For me personally, there are a few technical questions that have to be 
resolved on the list first.

Under the assumption that the trust stores will be used for TLS (maybe 
potential other things), I am not sure if the YANG module is an 
appropriate place to make some (maybe implicit?) 
"mandatory-to-implement" decisions. If there can be (and I think 
effectively there should be, but I do not know the appropriate place for 
them) prescriptive statements here, I would recommend the following 
proposals for the use with TLS:

1.) With respect to the format of the "raw" pub-key, I propose that the 
structure defined in section 3 of RFC 7250 MUST be used.

2.) With respect to cipher suite and interoperability, I propose to make 
RFC 7151 and RFC 4492 (basically the NIST curve and its format 
extensions) mti for raw pub-key and to point to RFC 7250 for guidance & 
to make RFC6635 mti for psk.

3.) With respect to key identities, I propose that raw pub-key 
identities as specified in RFC 6920 and a minimum hash length enabled by 
mode sha-256-120 MUST be used & to support and recommend the use of 
Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the 
corresponding security considerations (section 7 in RFC 4279).

My first question - on a technical level: do these proposals in the 
context of using TLS sound reasonable to the group?

My second question - on a semantic level: do these normative 
requirements belong here?

My third question - on a noob level :) If they belong here, where would 
these mandatory requirements be spelled out?

Viele Grüße,


On 06.11.19 04:45, Kent Watsen wrote:
> Hi Balázs,
>> I see some FIXMEs in ietf-crypto-types and related models. I would be 
>> interested about the current state of them and possibility to clean 
>> them up.
> Yes!  thanks for taking this up.
>>  1. Key-format (symmetric-key, public-key, asymmetric-key-pair)
>> I assume the idea here is to make it possible to have choices for the 
>> ASN.1 types holding the keys. If this flexibility for formats is 
>> necessary I don’t have any objection to them but having a single 
>> agreed type for these different use cases would also suffice.
> I believe here you're referring to the 3 instances of lines like:
>        leaf key {
>          nacm:default-deny-all;
>          type binary;
>          //must "../key-format";  FIXME: remove comment if approach ok
>          ...
>        }
> FWIW, the whole "key-format" leaf is still being sussed out (your 
> opinion would be helpful on that thread as well) but, so far it seems 
> promising.  The reason these lines are commented out is because 1) the 
> WG hasn't committed to this path yet and 2) I didn't want to update all 
> the examples in all the drafts (other than truststore and keystore) to 
> add a "key-format" leaf until the WG had more consensus on the 
> "key-format" leafs.
> I don't understand your last comment/sentence.  Can you provide an example?
>> 2.attributes in asymmetric-key-pair-with-cert(s)-grouping
>> I think attributes should be kept optional. If there is anything else 
>> besides subject seen mandatory maybe it should be extracted out from 
>> attributes and be spelled out a separate leaf, but I don’t think there is.
> I believe here you're referring to the 2 instances of lines like:
>          leaf attributes {
>            type binary; // FIXME: does this need to be mandatory?
>            ....
>          }
> These are in the "generate-certificate-signing-request" actions found 
> inside the asymmetric-key-pair-with-cert(s)-grouping.
> Hmmm, are you claiming that "attributes" are not required in order to 
> generate a CSR?  I think the CSR itself MUST have attributes (right?) 
> so, if not specified, what default values are used?
>>  3. PSK and raw public keys
>> The use case of PSK and raw public keys are not the most urgent in my 
>> opinion which now slows a bit the progress of these drafts, but let’s 
>> make an attempt to finalize them.
> Agreed, but they are legal for TLS and a WG member stated that they were 
> needed in order to support another IETF WG's efforts.  A quick 
> resolution would be best!
>> raw-public-keys: I see these were added due to RFC 7250 and 8446. I 
>> guess in truststore this is a separate container to distinguish from 
>> SSH host keys. For configuring the private part I think keystore 
>> already gives support for this case with the asymmetric key (w/o cert) 
>> and in the client/server drafts Kent’s proposal could be used (I 
>> replaced raw public key with existing type, shouldn’t that be useable 
>> straight away?)
>>     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-asymmetric-key-grouping;
>> I would also prefer if these choices are in features, so that an 
>> implementation can choose.
> To your first sentence, yes, "psk" (and "raw-public-key") are top-level 
> nodes in truststore, as can be seen here 
> ( 
>    Note, the trust-anchors draft accidentally doesn't include the 
> ietf-truststore.yang module.
> The body of your comment above seems to be about supporting the 
> secret-half of the PSK and RPK within the Keystore.  I've raise this 
> question a couple times previously to Henk (who's asking for the PSK/RPK 
> add), but he's not responded yet as to if doing so is important (though 
> I can only imagine that it does).   With that said, I think your YANG 
> snippet is meant to be in ietf-tls-server and ietf-tls-client modules 
> (right?).  I'm having a hard time following the "I replaced raw public 
> key with existing type, shouldn’t that be useable straight away?" comment.
> To your last sentence regarding features, could you provide an example 
> of what you mean?
> PS: none of this goes to the FIXME in the ietf-crypto-types.  I had 
> previously asked Henk to provide some text here as well but, apparently, 
> like all of us at this time, he's been busy!
>> psk: given that the asymmetric keys without certs were covered by host 
>> keys and raw public keys, I think psk should only be symmetric keys. 
>> Symmetric keys are then sensitive/secret data and as such I believe 
>> they should only be referenced from keystore. Seeing them in 
>> truststore was unexpected for me. When it comes to their use, clients 
>> and servers should be extended with following configuration (and I 
>> assume we talk of TLS clients and servers only):
>>     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-asymmetric-key-grouping;
>>                        uses ks:/local-or-keystore-symmetric-key-grouping/;
>> Latter grouping would be a new one, but it would use existing 
>> constructs and terms from keystore. I don’t think we need new ones. 
>> Selected cipher suites will need to have PSK in them for using 
>> symmetric key (similar match needed for the others). Note that 
>> symmetric keys can be used for other cases than TLS PSK, for example 
>> SNMPv3 USM. Again, features would be necessary (those could be saying 
>> x.509 or raw-public-key or psk).
> Correct, I said the same (that PSKs are essentially symmetric keys) 
> before as well.  Regarding only being referenced to keystore, why not 
> also support them being local-definitions too?  Certainly not a problem 
> if encrypted and, even when not encrypted, then they can be "protected" 
> by NACM-like mechanisms, right?   Why was/is seeing them in truststore a 
> surprise, perhaps because they're not encryptable there?  I agree that 
> symmetric keys can be used beyond PSK (and encryption of the asymmetric 
> keys, the original use case).  Regarding features, again, please provide 
> a YANG-snippet so it is clear to me (and all) what you mean.
> Thanks!
> Kent
> _______________________________________________
> netconf mailing list