[netconf] Paul Wouters' Discuss on draft-ietf-netconf-keystore-30: (with DISCUSS)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-netconf-keystore-30: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Roman's discuss with respect to the backup/restore procedure. Perhaps
limit it to say that a global KEK could be used to facilitate this, but not go
into details on how this would work with diagrams?

Similar to draft-ietf-yang-crypto-types:

     |     +--rw certificates
     |     |  +--rw certificate* [name]
     |     |     +--rw name                      string

Certificate identity is either done by entire DN, The Common Name (CN) RDN,
or by a list of subjectAltName (SAN) entries. Can the latter be expressed
here? Should a type be introduced? ("CN", "DN", "SAN") ? Should the type be
a list as 1 certificate can have multiple identities via multiple SAN entries.

See also:

     +--rw end-entity-cert-with-key* [name]
        +--rw name
        |       string

Section 4.1:

        A server MUST possess (or be able to possess, in case the KEK has
        been encrypted by yet another KEK) a KEK's cleartext value so that
        it can decrypt the other keys in the configuration at runtime.

Perhaps "MUST possess access to KEK or API using the KEK"? A server might
be using a TEE and not really have the KEK itself, but it can send a decryption
job to an API inside the TEE that could use the KEK and return the decrypted
key. In this case, the server does sort of "possess" the key but never its
"cleartext value".

Section 4.2:

        Implementations SHOULD provide an API that simultaneously generates and
        encrypts a key (symmetric or asymmetric) using a KEK.

Should that say "(symmetric or private asymmetric)" ?

Section 5.1:

        In order to satisfy the expectations of a "keystore", it
        is RECOMMENDED that implementations ensure that the keystore
        contents are encrypted when persisted to non-volatile memory.

I would probably add "and ensure keystore contents that have been decrypted in
volatile memory are zeroized when not in use".