Subject: [netconf] WG LC for three drafts

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 2 Jun 2020 16:48:07 -0700

NETCONF WG,

The authors of

- draft-ietf-netconf-crypto-types
- draft-ietf-netconf-keystore
- draft-ietf-netconf-trust-anchors

have indicated that these drafts are ready for Last Call (LC).

This kicks of a 2 week WG LC for the three drafts. Please review and send any comments to the WG mailing list or by responding to this e-mail. Comments can be statements such as, I read/reviewed the document and believe it is ready for publication, or I have concerns about the document. For the latter, please indicate what your concerns are. 

Any reports on implementation status or plans to implement are also very useful.

Thanks.

Mahesh Jethanandani (as co-chair)
[email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 12 Jun 2020 17:42:06 +0000

Hi Kent,

I have been reading draft-ietf-netconf-crypto-types, and the thread: Virtual
"hum" for the "key generation" issue discussed at virtual meeting.

I have a couple questions on the previous "asymmetric-algorithm-type"  and
what is now in "asymmetric-key-pair-grouping".  My reading is that instead
of the previous ENUMs of -v14, other applications/WGs will now need to
create identities for the various algorithm types.  And this is fine.

If I have this correct, then each of the TCG Algorithm Registry ID values of
TPM2 specifications in Table 9
https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-2-
Structures-01.38.pdf 
could have its own identity.   And there would be no barrier to each of
these identities also having another base identity that might be
"tpm2-algorithm".  In this correct?

If this is correct, my second question is whether there will be an attempt
to ask other YANG models to import these application identities elsewhere?
As you and Rob note in the thread, trying to predict the desired identity
inheritance hierarchy is non-trivial.

Thanks,
Eric

> -----Original Message-----
> From: netconf <[email-masked]> On Behalf Of Mahesh
> Jethanandani
> Sent: Tuesday, June 2, 2020 7:48 PM
> To: Netconf <[email-masked]>
> Subject: [netconf] WG LC for three drafts
> 
> NETCONF WG,
> 
> The authors of
> 
> This kicks of a 2 week WG LC for the three drafts. Please review and send
any
> comments to the WG mailing list or by responding to this e-mail. Comments
> can be statements such as, I read/reviewed the document and believe it is
> ready for publication, or I have concerns about the document. For the
latter,
> please indicate what your concerns are.
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 12 Jun 2020 20:03:13 +0000

Hi Kent,

I have been reading farther, and I see that the full
[email-masked] has been removed from -v15.  That is where
the TCG identity algorithms might have been merged in my thread below.

A few thought based on that:

(1) In the draft-ietf-netconf-crypto-types, in the YANG model you should
likely remove the description text which claims support for "algorithm" in
three of the grouping statements.

(2) Are there plans to evolve iana-hash-algo.yang anywhere?  In your May
14th message, you  say :  "Assuming a future effort mimicked Option #2, then
"yes", as I'd expect an "ietf-ssh-common:generate-asymmetric-key" RPC to
contain an "input" node that is an identityref to the
"ssh-asymmetric-algorithm" identity.".   I would be willing to help on that
work.

Thanks,

Eric

> From: netconf <[email-masked]> On Behalf Of Eric Voit (evoit)

> Sent: Friday, June 12, 2020 1:42 PM

> To: Kent Watsen <[email-masked]>

> Cc: Netconf <[email-masked]>

> Subject: Re: [netconf] WG LC for three drafts

> I have been reading draft-ietf-netconf-crypto-types, and the thread:

Virtual

> If I have this correct, then each of the TCG Algorithm Registry ID values

of

> https://www.trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-

> Part-2-

> these identities also having another base identity that might be "tpm2-

> algorithm".  In this correct?

> If this is correct, my second question is whether there will be an attempt

to

> ask other YANG models to import these application identities elsewhere?

> > This kicks of a 2 week WG LC for the three drafts. Please review and

> > send

> > comments to the WG mailing list or by responding to this e-mail.

> > Comments can be statements such as, I read/reviewed the document and

> > believe it is ready for publication, or I have concerns about the

> > document. For the

> > Any reports on implementation status or plans to implement are also

> > very useful.

---

From: tom petch <[email-masked]>
Date: Sat, 13 Jun 2020 11:29:47 +0000

I have concerns about trust-anchors and crypto-types.  They are both more or less non-existent when it comes to text.  I do not want to have to reverse engineer the YANG or XML to find out what RPC or action there are, what types of cipher suites and such like are supported - and perhaps those that are not such as raw keys.  I would expect there to be five or ten pages of such in each.  Look for example at layer0-types or layer1-types for modules with what I would regard as adequate text.

Tom Petch

From: netconf <[email-masked]> on behalf of Eric Voit (evoit) <evoit=[email-masked]>
Sent: 12 June 2020 21:03

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Jun 2020 14:35:10 +0000

Hi Eric,

Thank you for your review.  This message addresses both your prior messages…

> On Jun 12, 2020, at 4:03 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Kent,
>  
> I have been reading farther, and I see that the full [email-masked] has been removed from -v15.  That is where the TCG identity algorithms might have been merged in my thread below.
>  
> (1) In the draft-ietf-netconf-crypto-types, in the YANG model you should likely remove the description text which claims support for "algorithm" in three of the grouping statements.

Good catch!  Fixed here:

https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b49ba5e9db0d6c417 <https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b49ba5e9db0d6c417>

>  (2) Are there plans to evolve iana-hash-algo.yang anywhere?  In your May 14th message, you  say :  "Assuming a future effort mimicked Option #2, then "yes”, as I’d expect an "ietf-ssh-common:generate-asymmetric-key” RPC to contain an “input” node that is an identityref to the “ssh-asymmetric-algorithm” identity.".   I would be willing to help on that work.

I have no plans to work on the "algorithms” problem again.  Not that I wouldn’t like to, but I need to scale back how much unsupported time I volunteer for.  Generally speaking, I’m gracefully winding down my work in progress, while being hyper-cautious about signing up for new work.  This is why, e.g., I’m not pushing "YANG-next” or “restconf-collections” anymore, though both are really important to me.  That said, I’m open to contract-work, if that makes sense at all...

More below.

That was the idea at the time but, as you noticed, we since ditched the “algorithms” node altogether  :sigh:

> > If I have this correct, then each of the TCGAlgorithm Registry ID values
> of

I believe so.  I haven’t looked at the TCG Algorithm Registry, but certainly, "identity-stmt” allows multiple "base-stmt".   Some might be concerned for interoperability, but a solution might support polymorphic definitions.  Regardless, the original plan was (and I assume would be again, if/when the work is picked up) to enable the server to specify (e.g., via a “config false” list) which algorithms it supports.

> > inheritance hierarchy is non-trivial.

I’m unsure about this, but I think polymorphism would go a long way to alleviate the issue...

Kent // as a contributor

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Jun 2020 15:17:29 +0000

Hi Tom,

> On Jun 13, 2020, at 7:29 AM, tom petch <[email-masked]> wrote:
> 
> I have concerns about trust-anchors and crypto-types.  They are both more or less non-existent when it comes to text.  I do not want to have to reverse engineer the YANG or XML to find out what RPC or action there are, what types of cipher suites and such like are supported - and perhaps those that are not such as raw keys.  I would expect there to be five or ten pages of such in each.

This is an interesting comment.   How do other folks feel about this?

Generally, perhaps to a fault, I try to let the YANG modules do the talking.  Not only is the YANG syntax more exact, but it eliminates potentially-inconsistent duplicate text and, of course, the effort to create the duplicate text.  

That said, now that we’re near/at the end, creating some duplicate text may now be reasonable.  FWIW, there is no limitation on cipher-suites but, perhaps to your point, some introduction text could say that.  

A reasonable compromise might be to mimic what I did in Section 2 of draft-kwatsen-netconf-sztp-csr, whereby it has my normal (overview/diagrams + examples + yang module) subsections, but there’s more text surrounding the diagrams and examples making those sections more readable...

It’s funny that you say you don’t want to reverse-engineer the YANG, as many times I feel the opposite, not wanting to have to read the RFC, when the YANG module should be self standing.  I’m not minimizing your critique, just finding humor in the irony.  ;)

>  Look for example at layer0-types or layer1-types for modules with what I would regard as adequate text.

I recently answered this question for Mahesh here: https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/ <https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/>

Kent // contributor

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 15 Jun 2020 21:12:50 +0000

>From Kent Watsen, June 15, 2020 11:17 AM

Hi Tom,

On Jun 13, 2020, at 7:29 AM, tom petch <[email-masked] 
<mailto:[email-masked]> > wrote:

I have concerns about trust-anchors and crypto-types.  They are both more or 
less non-existent when it comes to text.  I do not want to have to reverse 
engineer the YANG or XML to find out what RPC or action there are, what types 
of cipher suites and such like are supported - and perhaps those that are not 
such as raw keys.  I would expect there to be five or ten pages of such in 
each.

Generally, perhaps to a fault, I try to let the YANG modules do the talking. 
Not only is the YANG syntax more exact, but it eliminates 
potentially-inconsistent duplicate text and, of course, the effort to create 
the duplicate text.

<eric> I prefer minimal, non-duplicative RFC content where possible.  Since 
the YANG model has to have the content anyway, it might as well provide the 
structural basis for the critical content.

Eric

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 16 Jun 2020 16:37:38 -0700

The WGLC on these three drafts has received insufficient review at this time. I am going to extend the LC by another week to allow for more review of these documents. While specific comments would be great, even saying “I have reviewed the draft, and support its publication” is helpful.

As a reminder, we are following option 3 in this message <https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/>. What that means is that once Kent has updated the tcp-client-server draft, it will be added to this set of drafts for LC before 108. The remaining drafts, ssh-client-server, tls-client-server http-client-server, netconf-client-server, restconf-client-server will be sent for LC after 108.

Thanks.

> On Jun 2, 2020, at 4:48 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> NETCONF WG,
> 
> The authors of
>

---

From: tom petch <[email-masked]>
Date: Wed, 17 Jun 2020 07:54:18 +0000

From: netconf <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Sent: 17 June 2020 00:37

<tp>
Sorry to be contrary but I have reviewed the draft and do not support publication was my take on  the types as I want to read text before I reverse engineer the YANG.  For all three, and probably for those yet to come, I think that they all need something that places them in context because there are so many of them and they interact.  The ASCII diagram in them currently is likely fine for those of us who have seen them evolve but likely inadequate for those outside the WG.  (Of course those who are new to the I-D will not have the baggage of history and so may not have such a problem:-)  Think of the TSVWG author who wants to know where to find what to include in their model.  Should there be a separate  I-D providing an introduction?  May be.
Tom Petch

As a reminder, we are following option 3 in this message<https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/>. What that means is that once Kent has updated the tcp-client-server draft, it will be added to this set of drafts for LC before 108. The remaining drafts, ssh-client-server, tls-client-server http-client-server, netconf-client-server, restconf-client-server will be sent for LC after 108.

Thanks.

On Jun 2, 2020, at 4:48 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

NETCONF WG,

The authors of

Thanks.

Mahesh Jethanandani (as co-chair)
[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2020 12:53:28 +0200

I have reviewed the I-Ds today and here are my comments:

* general comments

  - These drafts needs serious reviews by security domain experts.
    This all looks reasonable to me but since this is all about
    security, we need to set the bar high to get things right.

  - I think the work is in a good shape but the documents need another
    round of tweaks to get them ready.

* draft-ietf-netconf-crypto-types-15.txt

  - I agree with others that this document lacks introductory
    material.

  - Perhaps the title should reflect that this document is not
    just defining types but also groupings.

  - The public-key-grouping says that it captures a public key and its
    associated algorithm but I am not sure how this is done or is the
    idea that every algorithm requires a different public-key-format?

  - The asymmetric-key-pair-grouping says that it captures a private
    key and its associated public key and algorithm but I am not sure
    how this is done or is the idea that every algorithm requires a
    different private-key-format? I also wonder how this grouping
    captures the associated public key.

  - Do we have to be prepared for alternate cert formats in the
    future?

  - The certificate-expiration notification of the
    trust-anchor-certs-grouping probably needs adjustment; I assume
    this applies to any certificate the the cert leaf-list.

  - Is there any semantic difference between
    trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why
    do we need two groupings? Same question for
    trust-anchor-certs-grouping and end-entity-certs-grouping. If
    there is a semantic difference, perhaps this should be highlighted
    in the grouping description.

  - I have not checked the examples.

* draft-ietf-netconf-trust-anchors-10.txt

  - I agree with others that this document lacks introductory
    material. I am personally not a fan of one sentence sections
    but that may be just a personal style / preference issue.

  - The idea that there are groupings that support locally defined
    crypto keys or references to a centralized trust store really
    deserves to be explained upfront. Yes, I can reverse engineer this
    from the definitions, but people who need to decide whether they
    want to implement this module may not have the time and energy to
    do this. Notice that the abstract only talks about bags that can
    be referenced.

  - How does the storage of user public ssh keys suggested in the
    example usage section relate to the data model in RFC 7317?

  - The authors listed on the document and in the yang module are
    different.

  - Do we need the truststore-supported feature? We do not have this
    in other YANG modules. Is the idea to distinguish implementations
    that only import groupings? Even in this case, should this not be
    handled by the yang library somehow?

  - Do the leaf names always look good in instance data? For example,
    is <truststore-reference> may not be the most descriptive name in
    instance data. Perhaps it would help to also have examples that
    show how various groupings are used, not just the bags.

  - I have to think about the 'copy to running' procedure described in
    section 3. Perhaps this is the way to go but who happens if things
    get out of sync?

  - Why is it useful to define truststore-grouping, i.e., why is this
    not just a part of the truststore container definition? How are
    the reference types going to work if you instantiate the
    truststore-grouping elsewhere?

  - I have not checked the examples.

* draft-ietf-netconf-keystore-17.txt

  - Looking at the overview figure (that is unfortunately to be
    removed), I wonder whether trust-anchors should be renamed to
    truststore as this seems to be the term used by the yang module.

  - I appreciate the introductory text that this I-D has (compared to
    the others).

  - Several pages of yang tree output without explanations is not very
    helpful. I suggest to break this into pieces and to explain for
    each grouping when it may be used (or not used).

  - I am not sure I understand the examples, more precisely, how
       <keystore-reference>rsa-asymmetric-key</keystore-reference>
    or
       <keystore-reference>
         <asymmetric-key>rsa-asymmetric-key</asymmetric-key>
         <certificate>ex-rsa-cert</certificate>
       </keystore-reference>
    will be interpreted.

  - What is the informative reference to RFC8342 in the YANG module?

  - Do we need the keystore-supported feature? See discussion above.

  - Should the support for encrypted keys be moved to the cryto-types
    module? Is there a reason why we add the feature to have keys
    encrypted here? Perhaps this is sensible, I am just trying to
    check whether this has been given some thought.

  - Why is it useful to define keystore-grouping, i.e., why is this
    not just a part of the keystore container definition? How are the
    reference types going to work if you instantiate the
    keystore-grouping elsewhere?

  - I have to think about the 'copy to running' procedure described in
    section 4. Perhaps this is the way to go but who happens if things
    get out of sync? What is a system provided cert is exceeding its
    lifetime (does this even lead to a stream of notifications)?

  - The text in 5.3 scares me a bit. Migrating root keys may be seen
    as a bad idea by some. If you have a new device with new root
    keys, then you better re-encrypt or re-key instead of patching the
    root key.  Or are you essentially saying that encrypted keys
    should be encrypted with a key-encryption-key instead of the 'root
    key'?

  - I am not sure how one implements the 'MUST ensure that the
    strength of the key being configured is not greater than the
    strength of the underlying secure transport' nor am I sure that
    the consequences are really desirable, i.e., I can never move to
    'more secure keys' than what the transport currently allows. I
    think I understand the argument that says a key can't be more
    trustworthy than the transport used to configure it but I do not
    think we should disallow upgrade paths.

  - I have not checked the examples.

/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: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Jun 2020 14:59:34 +0000

For what it's worth, I've had a couple of discussions with Kent on these over time.  I think requesting an additional security directorate early review is probaby a good idea.

        future?

No. :) If something come to displace X509v3, many things will have to undergo some fundamental changes.

---

From: tom petch <[email-masked]>
Date: Wed, 17 Jun 2020 16:23:31 +0000

From: netconf <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 13 June 2020 12:29

<tp>
I thought about the text I would like to see in crypto-types and starting with identity since they are simplest I came up with 
NEW
This module contains YANG identity for private keys, public keys and symmetric keys.

>From the base "private-key-format" there are derived identity for 
- rsa-private-key-format as defined in RFC 3447
- ec-private-key-format as defined in RFC5915 
- one-asymmetric-key-format as defined in RFC 5958,
          encoded using ASN.1 distinguished encoding rules
          (DER), as specified in ITU-T X.690.";
- encrypted-one-asymmetric-key-format, as defined in RFC 5958,
          encoded using ASN.1 distinguished encoding rules (DER),
          as specified in ITU-T X.690.";
      
>From the base "public-key-format" there are derived identity for 
- ssh-public-key-format as specified by RFC 4253, Section 6.6, i.e.:
- subject-public-key-info-format as described in RFC 5280 encoded using ASN.1
          distinguished encoding rules (DER), as specified in
          ITU-T X.690.";

>From the base "symmetric-key-format" there are derived identity for 
-  octet-string-key-format encoded as a raw octet string.
-  one-symmetric-key-format as defined in RFC 6031 and
          encoded using ASN.1 distinguished encoding rules
          (DER), as specified in ITU-T X.690.
-  encrypted-one-symmetric-key-format as defined
          in RFC 6031 and encoded using ASN.1 distinguished
          encoding rules (DER), as specified in ITU-T X.690.";
            Specification of Basic Encoding Rules (BER),
            Canonical Encoding Rules (CER) and Distinguished
            Encoding Rules (DER)

Obviously all I have done is take the text and reformatted it. I debated about keeping the references to CMS.  The aim is to tell the reader whether or not to dig deeper into the YANG in order to use it.  For groupings I see more new text needed

Tom Petch

Tom Petch

---

From: Kent Watsen <[email-masked]>
Date: Wed, 17 Jun 2020 17:59:29 +0000

HI Juergen,

Thank you for your review!

Responses below.

Kent

> On Jun 17, 2020, at 6:53 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Undoubtedly, though things are dramatically simpler now without trying to define the “algorithm” nodes.   

>    round of tweaks to get them ready.

Good to hear.  

FWIW, I’m aware of several implementations, of the higher-level drafts, which bodes well to these models being close.  I can’t vouch that every node has been implemented, but huge swaths have.

>  - I agree with others that this document lacks introductory

It’s a fair point.

Being a WG document, text-contributions would be greatly appreciated.  Perhaps the WG could divvy up sections?

>    just defining types but also groupings.

I’ve ping-ponged on this a few times myself.  

The idea was worse before, when the “algorithm” nodes were being defined, as then there were identities in the mix as well, which, if all were reflected in the title, was a mouthful.  At that time I silently resolved that “types” could be thought of in the general, as opposed to the specifically “typedefs”.  But now that the “algorithm” nodes are out, it seems more reasonable, how about:

OLD: Common YANG Data Types for Cryptography
NEW: Common YANG Data Types and Groupings for Cryptography

>    captures the associated public key.

Both of the above comments were mentioned by Eric and fixed here https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b49ba5e9db0d6c417 <https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b49ba5e9db0d6c417>.

>  - Do we have to be prepared for alternate cert formats in the

In theory, yes; in practice, unlikely.  Of course, we should attempt to do it right, so...

Searching for the strings “certificate” and “X.509”, I think the issue is just description text asserting things must be X.509 when not true.  For instance, CMS allows for non-X.509 certs and so it’s unnecessary for the text to say otherwise.  Is this your sentiment as well?

[update: I just saw Rich Salz’s comment on this.  It’s true the world is skewed to X.509-based certs.  Do we still attempt to makes the minimum description text adjustments?]

>    this applies to any certificate the the cert leaf-list.

Yes, a notification could be for any “cert” entry in the leaf-list.  What adjustment is needed?  Is it just the description text?  Or are you thinking that the notification will be unable to identify the specific leaf-list entry that is expiring?

For NETCONF, it seems that the XPath would be able to identity the specific certificate (e.g., [1], [2], etc.).   RESTCONF might be problematic though, maybe the full cert is listed?

Digging deeper, I note that “leaf-list cert” appears only in two groupings:

  1) the "end-entity-certs-grouping” grouping
       - this grouping isn’t used anywhere (AFAIK) and could be removed

   2) the "trust-anchor-certs-grouping” grouping
       - this grouping is used in the truststore draft, but only in the definition
         of the "local-or-truststore-certs-grouping” grouping, and then only to
         support the “local” case…
       - FWIW, the “truststore” case is a "certificate-bag-ref”, that is, a bag 
         of certs...
       - at first I was thinking that we could adjust the “local” case to use
         the "trust-anchor-cert-cms” typedef but, actually, it already does.
         That is, it is a leaf-list of CMS structs…
       - another option would be to expand the “local” case to be a “list”
         instead of a “leaf-list”.  This would necessitate each cert to have
         a “key” (e.g., name), but that is how it is in the truststore's bag
         definition, so probably okay...
  
?

>    in the grouping description.

There is a huge semantic difference (albeit, no syntactic difference), TAs and EEs are used in entirely different ways.

The “*-certs-grouping” groupings were discussed above, and maybe will be removed but, if they stay, the same comment applies (huge semantic difference).

>  - I have not checked the examples.

All examples are validated each time the draft is built.

>    but that may be just a personal style / preference issue.

Same response as above.

>    do this. Notice that the abstract only talks about bags that can

This goes with the previous comment, but it helps a lot to have the specific omission called out.

>    example usage section relate to the data model in RFC 7317?

Firstly, note that the ct:ssh-public-key-format identity defines the same structure as RFC 7317, but I think your question may be more along the lines of if there is a redundancy, to which, I don’t think so, at least not necessarily…

RFC 7317 regards system-level users, e.g., is SSH-ing directly to a server, whereas here, as well in the ssh-client-server draft, the SSH-server may be application-level.

That said, the truststore could (really, SHOULD) be used to configure the system-level SSH server as well, as it portends to have security protections beyond regular config.  This is analogous the folks migrating to storing TAs in system-level mechanisms, such as Mac’s “keychain”.

What makes sense to me is to have a future 7317bis that migrates that definition to use the “ts:local-or-truststore-public-keys-grouping” grouping.

>  - The authors listed on the document and in the yang module are

Fixed in my local copy.

>    handled by the yang library somehow?

The "truststore-supported” feature is used to prune out the “truststore” case from the various “local-of truststore” groupings.  Yes, it is for implementations that do not implement the module (they only import the groupings).  I’m unsure how YANG Library could be used differently, that is, it's already currently used to indicate if the module is implemented/imported as well as what features are supported.

>    instance data.

All of the downstream drafts (ssh-, tls-, netconf-, restconf-) have examples illustrating "truststore-reference” in use.  [and the ssh- and tls- drafts have examples illustrating "keystore-reference” in use].

> Perhaps it would help to also have examples that

This would entail defining an example module to instantiate those groupings (such as is done in the crypto-types and keystore drafts).  If the goal is to make this draft as readable as possible in a standalone fashion, then perhaps that should be done.  Or perhaps we could just point readers to the examples in the aforementioned drafts?

>    section 3. Perhaps this is the way to go but who happens if things

We previously had "require-instance false” statements (also in the keystore draft), but they were removed (see the Change Log) because it seemed skewed to throwout validation for 99% of the TAs/keys in orderbto support the 1% case for builtin TA/keys.  So we moved to the current approach, which isn’t ideal, but seems better then the alternative...

FWIW, it’s intended (though perhaps not stated) that the server will reject any attempt to configure a new TA certificate.  That is, only a subset of the certificate can appear in <running>.  Any attempt to configure a new cert, or change an exist cert, should cause the commit to fail.   In this way, configurations that refer to the builtin definitions can be assured that the values used are only those approved by the manufacturer. 

>    truststore-grouping elsewhere?

I use this grouping in a project outside the IETF, where there are a multiplicity of context specific truststores.  I use the features to disable to default “local-or-truststore” cases and then augment-in my own case statement containing a reference to my context-specific truststore.

>  - I have not checked the examples.

All examples are validated each time the draft is built.

>    truststore as this seems to be the term used by the yang module.

The artwork is helpful, but it’s easy to see that it won’t age well - right?  For instance, already there are other WGs using some of this work and, let’s not forget the “syslog” draft that has been parked in NETMOD for ~2 years due to a MISREF to the TLS draft...

>  - I appreciate the introductory text that this I-D has (compared to

Good to know, thanks.

>    each grouping when it may be used (or not used).

This suggestion is in line with the response I gave Tom, regarding it being consistent with what I did in the “sztp-csr” draft.  I think the trick is to rename the section from “Tree Diagram” to “Data Model Overview” and go from there...

>         <certificate>ex-rsa-cert</certificate>

I don’t follow.  I think that you’re in Section 3.2.2...the paragraph preceding the example says:

   The following example illustrates what two configured keys, one local
   and the other remote, might look like.  This example consistent with
   other examples above (i.e., the referenced key is in an example above).

Probably that text should say “…in the example found in Section 3.2.1”, but maybe your comment about something else?

>  - What is the informative reference to RFC8342 in the YANG module?

That comment is a holdover from -06, when there was a “require-instance false” in the YANG module.  I just removed that RFC8342 reference in my local copy.

>  - Do we need the keystore-supported feature? See discussion above.

Same response as above for the "truststore-supported” feature.

>    check whether this has been given some thought.

In order to persist an encrypted key, it is necessary to reference the other key that was used to encrypt the key (so the server knows how to decrypt the key).  

The expectation is that the other key will be in the keystore, but note that a “choice” node is used for the references, and all the existing cases are protected by “feature” statements, so that, e.g., a “local” key or key in a context-specific instance of the keystore grouping can be used alternatively.

To your point, we could move the essence of the encrypted-key support directly into the key groupings in the crypto-types draft, but leave the “case” statement empty, and then have the keystore draft augment in “case” statements for keys in the keystore, when the keystore module is “implemented”.  Makes sense?

>    keystore-grouping elsewhere?

Same response as above for the "truststore-grouping”.

>    lifetime (does this even lead to a stream of notifications)?

In addition to the comment above regarding Section 3 in the truststore draft…

Things getting out of sync here is less likely (then they are in truststore), in that builtin keys are undoubtedly going to be “hidden” and therefore any attempt to config a builtin key under a different name will fail, as a hidden key (where the secret key data is missing) cannot be configured.

We do want to support users adding user-defined certificates (e.g., LDevID), as is illustrated in Section 4.

>    should be encrypted with a key-encryption-key instead of the 'root

More the latter.  The 2nd-to-last paragraph intends to say this. 

>    think we should disallow upgrade paths.

Changed to a SHOULD in my local copy.

>  - I have not checked the examples.

All examples are validated each time the draft is built.

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2020 20:43:48 +0200

> No. :) If something come to displace X509v3, many things will have to undergo some fundamental changes.

I accept the answer and the answer helps to get work finished so its
likely the right answer. That said, 5 years ago, who would have
believed our dns traffic is json encoded blurbs over https?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Jun 2020 21:10:09 +0200

> NEW: Common YANG Data Types and Groupings for Cryptography

Works for me.
 
>          definition, so probably okay...

Giving certs a name and using a list may make things simpler. But I
have no overview of all the usage implications (since I did not look
at the other documents).

> There is a huge semantic difference (albeit, no syntactic difference), TAs and EEs are used in entirely different ways.

Yes, but if its the same structure, why do we need two definitions of
the structure?
 
> All examples are validated each time the draft is built.

Thats what I hoped / expected. ;-)
 
> RFC 7317 regards system-level users, e.g., is SSH-ing directly to a server, whereas here, as well in the ssh-client-server draft, the SSH-server may be application-level.

This assumes there is such a difference, which is an assumption but not a requirement.
 
> What makes sense to me is to have a future 7317bis that migrates that definition to use the “ts:local-or-truststore-public-keys-grouping” grouping.

Yes, perhaps it is OK to stay silent about and to keep a record
somewhere that this needs to be looked at when 7317 is being revised.

> The "truststore-supported” feature is used to prune out the “truststore” case from the various “local-of truststore” groupings.  Yes, it is for implementations that do not implement the module (the…

I assume (have not checked) that you don't toggle the implement bit in
the yang library if you just import type definitions and groupings.

> All of the downstream drafts (ssh-, tls-, netconf-, restconf-) have examples illustrating "truststore-reference” in use.  [and the ssh- and tls- drafts have examples illustrating "keystore-referenc…

I guess I will eventually have to look at them...
 
> This would entail defining an example module to instantiate those groupings (such as is done in the crypto-types and keystore drafts).  If the goal is to make this draft as readable as possible in…

My preference is to point to the other drafts. These are likely
non-normative references, i.e., they are not problematic process wise

> FWIW, it’s intended (though perhaps not stated) that the server will reject any attempt to configure a new TA certificate.  That is, only a subset of the certificate can appear in <running>.  Any a…

Spelling this out would make me happy. The server has to enforce
consistency here.

> I use this grouping in a project outside the IETF, where there are a multiplicity of context specific truststores.  I use the features to disable to default “local-or-truststore” cases and then aug…

Well, to do this properly, one would have to invent a way to make the
references to different truststores. You are essentially dropping the
truststore and adding new ones, no? Still a hack, like cut'n'paste.
 
> The artwork is helpful, but it’s easy to see that it won’t age well - right?  For instance, already there are other WGs using some of this work and, let’s not forget the “syslog” draft that has bee…

I can't follow, artwork is no different than text.

> This suggestion is in line with the response I gave Tom, regarding it being consistent with what I did in the “sztp-csr” draft.  I think the trick is to rename the section from “Tree Diagram” to “D…

Short tree diagrams very helpful, multi pages tree diagramm are almost
pointless (and can always be generated when needed). The art is to
slice things into meaningful pieces.

> Probably that text should say “…in the example found in Section 3.2.1”, but maybe your comment about something else?
   
Please ignore my comment, I was confused.

> To your point, we could move the essence of the encrypted-key support directly into the key groupings in the crypto-types draft, but leave the “case” statement empty, and then have the keystore dra…

I have no strong opinion - it just felt that adding encrypted keys
later adds additional noise, more groupings to understand and to deal
with.

> More the latter.  The 2nd-to-last paragraph intends to say this. 

Perhaps this recommendation should be spelled out clearer and the
§obscure copy root keys approach be given as a reason to have such
key-encryption-keys.

> Changed to a SHOULD in my local copy.

Works for me. 

/js

---

From: tom petch <[email-masked]>
Date: Thu, 18 Jun 2020 08:38:53 +0000

From: netconf <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: 17 June 2020 15:59
To: Juergen Schoenwaelder; Mahesh Jethanandani

        future?

<tp>
Rich

I have seen work in the IETF on alternative cert formats but cannot lay my hands on it.  It might have come from IEEE or BBF or some such.  As you say, replacing X.509 would cause widespread changes but an alternative alongside for some environments - IoT? - might happen in our lifetimes.

Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 18 Jun 2020 11:43:22 +0000

I thought some more and here is the text that I would have liked to have read in crypto-types before diving into the YANG.  It is a tribute to the painstaking work of Kent that almost all I have done is cut and paste, removing duplicate phrases.  The IPR is all Kent's.
====================================================

X This module contains YANG identity, typedef and grouping for use by YANG modules involved with security.

X.1 This module contains YANG identity for private keys, public keys and symmetric keys.

>From the base "private-key-format" there are derived identity for 
- rsa-private-key-format for use with RSA as defined in RFC 3447
- ec-private-key-format for use with Elliptic Curve as defined in RFC5915 [**format]
- one-asymmetric-key-format as defined for use with CMS (Cryptographic Message Syntax) as defined RFC 5958, encoded using ASN.1 DER (Distinguished Encoding Rules) as specified in ITU-T X.690.
- encrypted-one-asymmetric-key-format as defined for CMS use in RFC 5958, encoded using ASN.1 DER.
      
>From the base "public-key-format" there are derived identity for 
- ssh-public-key-format as defined for use with SSH as specified by RFC 4253, Section 6.6.
- subject-public-key-info-format as defined for use with X.509 in RFC 5280, encoded using ASN.1 DER.

- octet-string-key-format encoded as a raw octet string.
- one-symmetric-key-format as defined for use with CMS in RFC 6031 and
          encoded using ASN.1 DER
- encrypted-one-symmetric-key-format as defined for use with CMS 
          in RFC 6031 and encoded using ASN.1 DER

X.2 This module contains typedef for X.509 certificate, CMS structures and trust anchors.

'csr' is derived from 'binary' and is for use with a CertificationRequest          as specified in PKCS#10, RFC 2986, encoded in DER.  No other types are derived from this base.

'x509' (without the period) is derived from 'binary' and for use for a X.509 Certificate (RFC5280), encoded in DER.  From 'x509' are derived 
- trust-anchor-cert-x509 a X.509 self-signed certificate (RFC5280)
- end-entity-cert-x509 a X.509 certificate for end entities, i.e. a certificate that is neither self-signed nor having the 'cA' bit in the basic constraints extension set to true (RFC 5280 Section 4.2.10)

'crl' is derived from 'binary' and is for use for a X.509 'CertificateList' structure, as specified in RFC 5280, encoded in DER.  No other types are derived from this base.

'cms' is derived from 'binary' and for use for a CMS ContentInfo structure encoded in DER (RFC5652 Section 2).  From 'cms' are derived 
- data-content-cms 
           a CMS structure whose top-most content type MUST be
           the 'data content type' (RFC 5652 Section 4)
- signed-data-cms - a structure whose top-most content type MUST be the
          'signed-data content type' (Section 5 RFC 5652)
- enveloped-data-cms  
         "A CMS structure whose top-most content type MUST be the
          'enveloped-data content type' (Section 6 RFC 5652)
- digested-data-cms {
         "A CMS structure whose top-most content type MUST be the
          'digested-data content type' (Section 7 RFC 5652)
- encrypted-data-cms {
         "A CMS structure whose top-most content type MUST be the
          'encrypted-data content type' (Section 8 RFC 5652)
- authenticated-data-cms {
          "A CMS structure whose top-most content type MUST be the
          'authenticated-data content type' (Section 9 RFC 5652)

>From 'signed-data-cms' are derived
- trust-anchor-cert-cms is a CMS SignedData structure that contains a single chain of X.509 (RFC 5280) certificates which authenticate the certificate presented by a client or end-entity.  The chain must include a root certificate; this may be the only certificate present when that is also the certificate for the client or end-entity. Objects relating to the revocation status of the certificates MAY be present.  This uses the degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 certificates and revocation objects.

-  end-entity-cert-cms is a CMS SignedData structure that contains the end entity certificate itself and MAY contain any number of intermediate certificates leading up to a trust anchor certificate which MAY be included as well.  This differs from 'trust-anchor-cert-cms' in that the root certificate and intermediate certificates, if any, are optional.  Other certificates MUST NOT be present but objects relating to the revocation status of the certificates MAY be present.  This uses the degenerate form of the SignedData structure (RFC 5652 Section 5.2) as is commonly used to disseminate X.509 certificates and revocation objects.

X.3 This module contains YANG grouping related to keys and certificates. The groupings for keys all contain NACM (Network Configuration Access Control Model), RFC 8341, default deny for the key leaf itself.  The groupings for end entity certificates and for trust anchors contain a YANG notification that the certificate is, or is about to, expire and also contain a NACM default deny. 

symmetric-key-grouping contains a leaf whose type is derived from 'symmetric-key-format'.  The format of the key is a YANG 'choice' of 'binary' or 'empty'; the latter is for use with a hidden key.

public-key-grouping contains a leaf which is the public key in 'binary' and whose format is derived from the type 'public-key-format'.

asymmetric-key-pair-grouping uses the public-key-grouping and contains a leaf  for the private key format whose type is derived from the type private-key-format and for the key itself whose type is binary or empty; the latter is for use with a hidden key.       

trust-anchor-cert-grouping contains a leaf of type 'trust-anchor-cert-cms'

trust-anchor-certs-grouping contains a leaf list of type 'trust-anchor-cert-cms'

end-entity-cert-grouping contains leaf of type 'end-entity-cert-cms'

end-entity-certs-grouping contains a leaf list of type 'end-entity-cert-cms'

generate-csr-grouping contains a YANG action to generate a signed CertificationRequest); the associated node MUST have a 'public-key-format' value of 'subject-public-key-info-format'. 'input' to the action are the 'subject' and 'atributes' fields of  CertificationRequestInfo as specified in RFC 2986, Section 4.1, encoded in DER. 'output' of the action is a leaf of type 'csr' as described above.

asymmetric-key-pair-with-cert-grouping contains a private/public key pair and an associated certificate. The grouping uses; 
- asymmetric-key-pair-grouping
- end-entity-cert-grouping
- generate-csr-grouping
as defined above.

asymmetric-key-pair-with-certs-grouping is similar to 'asymmetric-key-pair-with-cert-grouping' but contains a list of end entity certificates for the public key where, for example, there are separate certificate for IDevID and LDevID [reference**]
====================================================

________________________________________
From: netconf <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 17 June 2020 17:23
To: Kent Watsen
Cc: Netconf
Subject: Re: [netconf] WG LC for three drafts or two of them

<tp>

Tom Petch

Tom Petch

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 18 Jun 2020 13:00:42 +0000

ITU is working on X509v4, but that isn't going to be smaller than X509v3 and not clear to me useful for IoT.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 18 Jun 2020 13:41:33 +0000

Hi Tom,

Thank you!

This text is a superset of the text sent yesterday, so I’ll focus on consuming this content instead.  Reading it, two thoughts arise:

1) Much of this text should surround tree diagram snippets.   As Juergen implied yesterday, a wall of tree diagram artwork alone doesn’t make for a great “overview”.

2) It is too bad that RFC 8340 doesn’t define a way to represent identities, features, or typedefs (note that both identities and features can form trees too).  I’ll likely devise my own format for the “overview” section, around which some of your text would go.

PS: I have no IPR on this work either, it all goes to the IETF.

Kent // contributor

> On Jun 18, 2020, at 7:43 AM, tom petch <[email-masked]> wrote:
>

---

From: tom petch <[email-masked]>
Date: Thu, 18 Jun 2020 15:34:34 +0000

From: Kent Watsen <[email-masked]>
Sent: 18 June 2020 14:41

Hi Tom,

Thank you!

<tp>
I am unconvinced about surrounding tree snippets in this case.  I note that Juergen said
'  - Is there any semantic difference between
     trust-anchor-cert-grouping and end-entity-cert-grouping, i.e., why
     do we need two groupings? Same question for
     trust-anchor-certs-grouping and end-entity-certs-grouping. If
     there is a semantic difference, perhaps this should be highlighted
     in the grouping description'
and if you are reverse engineering the YANG I think that that is a likely view.  What I did was put the text side by side. no intervening YANG or tree diagram or ..., when I think that the semantic difference is clearer to the reader.  It may then be a question as to whether or not we need both but I think that my formatting brings out the existing semantic difference which inserting anything YANG or YANG-like obscures.

Tom Petch

Kent // contributor

On Jun 18, 2020, at 7:43 AM, tom petch <[email-masked]<mailto:[email-masked]>> wrote:

________________________________________
From: netconf <[email-masked]<mailto:[email-masked]>> on behalf of tom petch <[email-masked]<mailto:[email-masked]>>
Sent: 17 June 2020 17:23
To: Kent Watsen
Cc: Netconf
Subject: Re: [netconf] WG LC for three drafts or two of them

From: netconf <[email-masked]<mailto:[email-masked]>> on behalf of tom petch <[email-masked]<mailto:[email-masked]>>
Sent: 13 June 2020 12:29

<tp>

Tom Petch

Tom Petch

From: netconf <[email-masked]<mailto:[email-masked]>> on behalf of Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>>
Sent: 12 June 2020 21:03

-----Original Message-----

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Mahesh

Jethanandani

To: Netconf <[email-masked]<mailto:[email-masked]>>

NETCONF WG,

The authors of

send

any

document. For the

latter,

very useful.

Thanks.

netconf mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: tom petch <[email-masked]>
Date: Tue, 23 Jun 2020 15:51:47 +0000

From: Salz, Rich <[email-masked]>
Sent: 18 June 2020 14:00

Rich
IEEE1609.2 is what I had in mind since it got quite a bit of attention on the TLS WG list in August 2018.  I don't know how widely it is used.

Tom Petch

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 23 Jun 2020 18:21:14 +0000

Hi Kent,

I am fine with extracting the Algorithm Types as you describe below.  

Still, there are people who need this info, such as the RATS WG.  Therefore as a starting point for the discussion in the RATS WG, I have created ietf-asymmetric-algs.yang <https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing/blob/master/[email-masked]>  which (non-accidentally) is named similarly to your iana-asymmetic-algs.yang model that isn't progressing right now to WGLC.  ietf-asymmetric-algs.yang has an immediate need by ietf-tpm-remote-attestation.yang <https://github.com/ietf-rats/draft-voit-rats-trusted-path-routing/blob/master/[email-masked]> , and will part of the next version of draft-ietf-rats-yang-tpm-charra <https://datatracker.ietf.org/doc/draft-ietf-rats-yang-tpm-charra/?include_text=1> .  It does follow what you suggest with the multiple base statements approach.

If nobody wants to steward a merged TCG & IANA identity inheritance hierarchy of algorithm types, we will shrink the identities within ietf-asymmetric-algs.yang to just those relevant to TCG/TPMs.  But hopefully there will be someone willing to steward a merged TCG & IANA inheritance hierarchy.

Eric

From: Kent Watsen <[email-masked]> 
Sent: Monday, June 15, 2020 10:35 AM
To: Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] WG LC for three drafts

Hi Eric,

 

On Jun 12, 2020, at 4:03 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

Hi Kent,

I have been reading farther, and I see that the full [email-masked] <mailto:[email-masked]>  has been removed from -v15.  That is where the TCG identity algorithms might have been merged in my thread below.

Good catch!  Fixed here:

https://github.com/netconf-wg/crypto-types/commit/690c016b201241e13a1e324b49ba5e9db0d6c417

More below.

Thanks,

Eric

> From: netconf <[email-masked] <mailto:[email-masked]> > On Behalf Of Eric Voit (evoit)

> To: Kent Watsen <[email-masked] <mailto:[email-masked]> >

> Cc: Netconf <[email-masked] <mailto:[email-masked]> >

Virtual

 

of

 

to

 

Kent // as a contributor

> > From: netconf <[email-masked] <mailto:[email-masked]> > On Behalf Of Mahesh

> > To: Netconf <[email-masked] <mailto:[email-masked]> >

> > [email-masked] <mailto:[email-masked]> 

> > [email-masked] <mailto:[email-masked]>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Jun 2020 18:21:34 +0000

>    IEEE1609.2 is what I had in mind since it got quite a bit of attention on the TLS WG list in August 2018.  I don't know how widely it is used.

oh that.  Thanks.