Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-keystore-30: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Murray,

Thank you for your valuable comments.
Please find responses below.

Kent


> On Feb 1, 2024, at 2:46 AM, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-netconf-keystore-30: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Roman's DISCUSS with respect to the text of Section 5.1.
> 
> ====
> 
> Additional comments from incoming AD, Orie Steele:
> 
> Same comment, as I made on draft-ietf-netconf-crypto-types, regarding base64
> encoding, consider a direct reference to
> https://datatracker.ietf.org/doc/html/rfc4648/#section-4
> 
>> These examples assume the existence of an example module called
> "ex-keystore-usage" having the namespace
> "http://example.com/ns/example-keystore-usage".
> 
> Since changing the URL changes the namespace, lets make this https before
> publishing?

Fixed. 

I converted all "http://example.com” to "https://example.com” (in all nine drafts)



> You might also consider using the `.example`,
> https://en.wikipedia.org/wiki/.example

I hadn’t see that before.  

But note the same page links `example.com`,
https://en.wikipedia.org/wiki/Example.com

Since `.example` seems both optional and unusual, I’d like to stick with the existing `example.com`

Okay?



> Under: Protocol accessible nodes
> 
> "encrypted-private-key/encrypted-private-key" is this duplication intentional?
> 
>> If the KEK is an asymmetric key, then the server MAY provide an API enabling
> the encryption of other keys or, alternatively, assume the administrators can
> do so themselves using the asymmetric key's public half.
> 
> Why not SHOULD?

Agreed.  Changed to SHOULD - thanks.


>> 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.
> 
> Is a cleartext value really needed here? or can the server just maintain an API
> for the key by reference.

Right, this was changed in my response just now to Paul.
The current text now more simply says this:

            A server MUST possess access to the KEK or an API using the KEK,
            so that it can decrypt the other keys in the configuration at runtime.

Good?



Thanks again,
Kent