Re: [netconf] Comment on typedef 'public-key-ref' of draft-ietf-netconf-trust-anchors-21

[[e-mail]]

Hi all,

Kent, fwiw the alto draft was already in the IESG review and that a new version is expected to come address the IETG review.

On the specific point about moving some items to draft-ietf-netconf-trust-anchor, this will introduce a direct normative dependency to draft-ietf-netconf-trust-anchor, which was indirect via draft-ietf-netconf-tls-client-server.

Having direct or indirect dependency won’t change the fact that the ALTO spec will be waiting in seems to be a large cluster for draft-ietf-netconf-trust-anchor, but this will require some effort to track whether changes to the groupings in draft-ietf-netconf-trust-anchor do not have implication on the ALTO spec.

Cheers,
Med (ALTO OAM doc Shepherd)

De : netconf <[e-mail]> De la part de Jensen Zhang
Envoyé : mercredi 13 décembre 2023 03:33
À : Kent Watsen <[e-mail]>
Cc : [e-mail]; [e-mail]; IETF ALTO <[e-mail]>
Objet : Re: [netconf] Comment on typedef 'public-key-ref' of draft-ietf-netconf-trust-anchors-21

Hi Kent,

Thanks for your quick response.

Maybe I did not make it clear. I am just pointing out a very simple specific issue in the current 'ietf-truststore' module, which is that the typedef 'public-key-ref' cannot be used by another module.

The reason is very simple: Based on the description, if module A wants to use this typedef to reference a public key in the central trust store, it is supposed to provide another sibling leaf node called 'public-key-bag' that has the typedef 'public-key-bag-ref', so that the public-key-ref can use the relative path '[ts:name = current()/../ts:public-key-bag]' to locate in which public-key-bag the referenced public key should be. However, in this relative path, 'public-key-bag' is prefixed by 'ts', it cannot reference the sibling leaf node 'public-key-bag' defined in module A correctly.

The fix should also be very simple: Just remove the prefix of the 'public-key-bag', i.e.,

OLD:
         + "[ts:name = current()/../ts:public-key-bag]/"
NEW:
         + "[ts:name = current()/../public-key-bag]/"
You mentioned that the 'ietf-restconf-server' module also uses the 'ietf-truststore' module. But does it use the typedef 'public-key-ref' anywhere? I don't find any other module that uses the current typedef 'public-key-ref'. Do you have such a successful example?

About your other feedback, please see my responses inline :)

Thanks,
Jensen

On Wed, Dec 13, 2023 at 2:36 AM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Jensen,


On Dec 12, 2023, at 7:47 AM, Jensen Zhang <[e-mail]<mailto:[e-mail]>> wrote:

Hi authors,

I am one of the authors of the draft-ietf-alto-oam-yang draft. Our draft is trying to reuse some groupings and typedefs in this document to support some TLS authentication features. But we find the current typedef 'public-key-ref' cannot be used by another module.

To be more concrete, in the current document, the path of the typedef 'public-key-ref' enforces a prefix of the relative path to the sibling 'public-key-bag' leaf:

   typedef public-key-ref {
     type leafref {
       path "/ts:truststore/ts:public-key-bags/ts:public-key-bag"
         + "[ts:name = current()/../ts:public-key-bag]/"
         + "ts:public-key/ts:name";
     }
     ...
   }

From my understanding, this typedef is for other modules to reference a public key in the trust store. The sibling 'public-key-bag' leaf should be in the same module of the leaf using this typedef, instead of the module 'ts'.

To make this typedef usable, I believe it should look like the following:

   typedef public-key-ref {
     type leafref {
       path "/ts:truststore/ts:public-key-bags/ts:public-key-bag"
         + "[ts:name = current()/../public-key-bag]/"
         + "ts:public-key/ts:name";
     }
     ...
   }

Otherwise, we have to define another typedef in our own module like this: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/blob/284d2e630cec00f752ea94f586469797786c6f57/yang/ietf-alto.yang#L612-L628

This is my first time looking at Alto.  It may take me a little to fully grok what’s going on.  Please let me know if you think a call would be helpful.

Looking at the linked YANG module, I see that it looks very much like the "ietf-restconf-server" module’s grouping "restconf-server-listen-stack-grouping”, which is fine.

I take it that Alto is okay referencing the central truststore (not defining its own instances of "truststore-grouping") as well as supporting inlined definitions.  I do not see the Alto module augmenting the centralized truststore and, in general, it seems to behave just like the ietf-restconf-server module, though I’m sure I’m missing something  ;)

What I don’t understand is why what seems to work in ietf-restconf-server doesn’t work in ietf-alto.  Can you help me understand?

Separately, did ALTO WG ever consider renaming to “ietf-alto-server”?  Would there be value to extending that convention for consistency?

The module 'ietf-alto' provides both server and client configurations. I guess you are suggesting to separate them into two modules. It may not be necessary unless somebody has a strong opinion on this. But still thanks for your comment.


One last thought, I notice that ietf-alto defines a number of typedefs that seem generic enough to move to ietf-truststore.  Is this thought yours as well?

Good point. The reason why ietf-alto defines those typedefs and groupings is that we don't find the reusable typedefs and groupings in another module. It definitely will be great if ietf-truststore can provide some of them.

Specifically, I believe the typedef 'public-key-ref' and grouping 'truststore-public-key-ref' can be moved to ietf-truststore.

But for the typedefs and groupings related to the inline certificates, I have no idea how to make them generic properly. Because the inline certificates defined by the 'inline-or-truststore-certs-grouping' grouping will have different absolute paths when it is used in different modules.




Thanks,
Jensen


Kent   // author

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.