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

[Balázs Kovács <[e-mail]>]

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