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

From: Balázs Kovács <[email-masked]>
Date: Tue, 5 Nov 2019 15:17:19 +0000

Hi,

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.

  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.

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.

  1.  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.

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.

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).

Br,
Balazs

---

From: Kent Watsen <[email-masked]>
Date: Wed, 6 Nov 2019 03:45:18 +0000

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.

> 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?

> 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?

> 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?)
>  

To your first sentence, yes, "psk" (and "raw-public-key") are top-level nodes in truststore, as can be seen here (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1 <https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1>).   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!

> 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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 Nov 2019 08:56:00 +0100

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,

Henk

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.
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
>            ....
> 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?)
> To your first sentence, yes, "psk" (and "raw-public-key") are top-level 
> nodes in truststore, as can be seen here 
> (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1). 
>    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.
> 
> 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):
>>                        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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Balázs Kovács <[email-masked]>
Date: Wed, 6 Nov 2019 14:27:10 +0000

Hi Kent,

      leaf key {
        nacm:default-deny-all;
        type binary;

Balazs> Ok, then let’s wait for WG decision. Well, I just say that the earlier ways of communicating the key formats were adequate from my point of view, which was that in documentation it was said that for RSA use RSAPrivateKey and for EC use ECPrivateKey, and similarly for other types. I’m also ok with the key-format approach if preferred by the WG.

In earlier versions:

           description
             "The value of the binary key.  The key's value is
              interpreted by the 'algorithm'.  For example, a DSA key
              is an integer, an RSA key is represented as RSAPrivateKey
              as defined in RFC 8017<https://tools.ietf.org/html/rfc8017>, and an ECC key is represented as
              ECPrivateKey as defined in RFC 5915<https://tools.ietf.org/html/rfc5915>."

        leaf attributes {

Balazs> In RFC2986<https://tools.ietf.org/html/rfc2986#section-3> the attributes are said to be optional. We just need the subject DN as mandatory, don’t we?

        1. A CertificationRequestInfo value containing a subject

           distinguished name, a subject public key, and optionally a

           set of attributes is constructed by an entity requesting

           certification.

To your first sentence, yes, "psk" (and "raw-public-key") are top-level nodes in truststore, as can be seen here (https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-07#section-2.1).   Note, the trust-anchors draft accidentally doesn't include the ietf-truststore.yang module.

Balazs: You had an example earlier in an email from 10/8/2019, which is about the TLS client/server models. Below, you are referring to some possibly new groupings that you wanted to propose. I don’t understand though why you mentioned these new groupings since ‘ks:local-or-keystore-asymmetric-key-grouping’ (RPK) and something new that just refers to a keystore symmetric key, such as ‘ks:local-or-keystore-symmetric-key-grouping’ (PSK) should be good. This latter I think would be a new grouping, but with existing terminology.

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;

container <client-identity or server-identity> {
    choice auth-type {
        mandatory true;
        case certificate {
            if-feature x509-certificate-auth;
           uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
       }
        case raw-public-key {
            if-feature raw-public-key-auth;
           uses ks:local-or-keystore-asymmetric-key-grouping;
       }
        case psk {
            if-feature psk-auth;
           uses ks:local-or-keystore-symmetric-key-grouping;
       }

I assume these features would then need to be defined in the TLS client/server draft.

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?

Balazs> Local definitions are ok too that’s why I used a hypothetical grouping name  ks:local-or-keystore-symmetric-key-grouping.

  Why was/is seeing them in truststore a surprise, perhaps because they're not encryptable there?

Balazs> When PSKs are used then both communicating ends use the shared key for signing and verifying messages. Then one configuration seems enough that is either local or from keystore, why would it be necessary to set it up yet another time for verification from local or truststore? This would mean there is no need for a PSK option when configuring how to  verify the peer.

container <client-authentication or server-authentication> {
    choice auth-type {
        mandatory true;
        case certificate {
            if-feature x509-certificate-auth;
            container ca-certs {

                uses ts:local-or-truststore-certs-grouping
            }
            container server-certs {

                uses ts:local-or-truststore-certs-grouping
            }
       }
        case raw-public-key {
            if-feature raw-public-key-auth;
                uses ks: local-or-truststore-raw-pub-keys-grouping
       }

No need for PSK config since it is already configured in client/server-identity.

Or what is the reasoning why it is necessary to configure a PSK from truststore?

 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

---

From: Kent Watsen <[email-masked]>
Date: Sat, 9 Nov 2019 02:35:46 +0000

Hi Henk,

> 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:

I understand the sentiment expressed, but the details are muddy.  I presume the below are the clarifications, but even they are not clear to me...   ;^)

> 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.

Is this what you have in mind?

OLD:

  typedef raw-public-key {
    type binary;
    description
      "The binary key data for a raw public key.
       FIXME: specify how it is formatted.";
  }

NEW:

  typedef raw-public-key {
    type binary;
    description
      "A SubjectPublicKeyInfo structure, as specified in RFC
       5280, encoded using ASN.1 distinguished encoding rules
       (DER), as specified in ITU-T X.690.";
    reference
      "RFC 7250:
         Using Raw Public Keys in Transport Layer Security
         (TLS) and Datagram Transport Layer Security (DTLS).
       RFC 5280:
         Internet X.509 Public Key Infrastructure Certificate
         and Certificate Revocation List (CRL) Profile.
       ITU-T X.690:
         Information technology - ASN.1 encoding rules:
         Specification of Basic Encoding Rules (BER),
         Canonical Encoding Rules (CER) and Distinguished
         Encoding Rules (DER).";
  }

If so, then I think Balazs's idea to use ks:local-or-keystore-asymmetric-key-grouping is a good one, as it ultimately becomes a SubjectPublicKeyInfo structure for the public-half, and a one of a few different kinds of structures for the private half. 

> 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.

Can you propose the draft-text you have in mind?

> 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).

Can you propose the draft-text you have in mind?

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

This is hard to answer without the understanding the change to the YANG module

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

You mean in the YANG module?  Where else might they be located?

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

In the YANG modules, we strive to define as much normative information as possible using YANG statements for automation but, when necessary, resort to "description" statements to define things.  But I think you know this already, so maybe you're asking a different question?

> Henk

PS: all the above regards RPKs, but how should PSK be defined?

OLD:

 typedef psk {
    type binary;
    description
      "The binary key data for a PSK (pairwise-symmetric or
       pre-shared key).  FIXME: specify how it is formmated.";
  }

NEW:

  ???

Is there any reason to not use a presumed ks:local-or-keystore-symmetric-key-grouping, that would ultimately become either an OctetString or a OneSymmetricKey?

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Mon, 11 Nov 2019 03:06:57 +0000

Hi Balazs,

>               as defined in RFC 8017 <https://tools.ietf.org/html/rfc8017>, and an ECC key is represented as
>               ECPrivateKey as defined in RFC 5915 <https://tools.ietf.org/html/rfc5915>." 

Yes, the previous way (example above) was adequate, but I believe the new way (i.e. using a key-format leaf) is better as:

1) it enables the a key-type (e.g., a symmetric key) do be expressed in different ways as needed (OctetString vs. OneSymmetricKey vs. EncryptedData)
2) it MAY (haven't tried to model it yet) be able to support encoding variations (DER vs PEM, and CMS vs. multi-part PEM)
3) it decouples the part that we are stuck on (i.e., the 'algorithm' node) and it being factored-out may provide more flexibility in that definition.

The WG hasn't discussed key-format yet.  Above is the first foray into it...do these arguments sound compelling?

> Balazs> In RFC2986 <https://tools.ietf.org/html/rfc2986#section-3> the attributes are said to be optional. We just need the subject DN as mandatory, don’t we?
>  
>  

Thank you.  I've removed these to comments, thus leaving the "attrubtute" nodes as NOT mandatory.

>                          uses ks:local-or-keystore-pre-shared-key-grouping;

Ah, now I understand, I and agree that this seems like the right way to do it, but see below...

>            uses ks:local-or-keystore-symmetric-key-grouping;

Better!  This uses the existing groupings (e.g., ks:local-or-keystore-asymmetric-key-grouping) whereas the above proposal defined new ones.  (see GitHub for latest files, though the commit is larger than it should be)

Henk, what do you think?

> I assume these features would then need to be defined in the TLS client/server draft.

Yes.

> Balazs> Local definitions are ok too that’s why I used a hypothetical grouping name  ks:local-or-keystore-symmetric-key-grouping.

Sorry, I glossed over the "local-" prefix in your earlier statement.

I agree that PSKs should be in Keystore when used for client-identity/server-identity nodes... (more below)

> No need for PSK config since it is already configured in client/server-identity.

Ack.   (see GitHub for latest files, though the commit is larger than it should be)

And, as a bonus, Keystore already defines support for encryption (unlike Truststore).

>  Or what is the reasoning why it is necessary to configure a PSK from truststore?

Somehow I thought that were being used in conceptually different ways, but I see now that's not really the case...

Thank you, Balazs, this message was most helpful!   

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 12 Nov 2019 09:10:49 +0000

Hi Kent,

Regarding this one:

Yes indeed. So the proposal is ok for me. Is there anything to discuss on the details of this to matter or the have the WG’s commitment?

Br
Balazs

From: Kent Watsen <[email-masked]>
Sent: Monday, November 11, 2019 4:07 AM
To: Balázs Kovács <[email-masked]>
Cc: [email-masked]
Subject: Re: FIXMEs in ietf-crypto-types and client/server models

Hi Balazs,

      leaf key {
        nacm:default-deny-all;
        type binary;

In earlier versions:

           description

        leaf attributes {

           certification.

                OLD

Henk, what do you think?

Yes.

Kent // contributor

---

From: Balázs Kovács <[email-masked]>
Date: Tue, 19 Nov 2019 09:19:11 +0000

Hi Kent,

I had a look at your changes related to our discussion. In general it looks good!

Some questions below:

container server-authentication {

…

case psk {

// no configuration required since it

// is the same as in client-identity!
}

Do we need the if-feature in case of this empty case? Is the empty case ok in general?

  grouping local-or-truststore-raw-pub-keys-grouping {
…
    choice local-or-truststore {
      mandatory true;
      case local {
        if-feature "local-definitions-supported";
        container local-definition {
…
          list raw-public-key {
…
            }
            uses ct:public-key-grouping;
          }
          uses ct:trust-anchor-certs-grouping;     /// <-- Is this a mistake?
        }
      }
      case truststore {
…
      }
…
    }
  }

Was the marked line left over as a mistake after a copy from local-or-truststore-certs-grouping?

Br,
Balazs

From: netconf <[email-masked]> On Behalf Of Balázs Kovács
Sent: Tuesday, November 12, 2019 10:11 AM
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] FIXMEs in ietf-crypto-types and client/server models

Hi Kent,

Regarding this one:

Br
Balazs

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 11, 2019 4:07 AM
To: Balázs Kovács <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: FIXMEs in ietf-crypto-types and client/server models

Hi Balazs,

      leaf key {
        nacm:default-deny-all;
        type binary;

In earlier versions:

           description

        leaf attributes {

           certification.

                OLD

Henk, what do you think?

Yes.

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Nov 2019 00:04:29 +0000

Hi Balazs,

> I had a look at your changes related to our discussion. In general it looks good!

Excellent.

> <snip>

Yes, I added a feature statement to my local copy.

> <snip> 

Yes, that was a mistake.  Thanks for catching it!

Kent // contributor