[netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-crypto-types-29: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-netconf-crypto-types-29: 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-crypto-types/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Similar to what Paul's DISCUSS says:

Section 3.5:

        That said, expert Security opinion suggests that already it is
        infeasible to break a 128-bit symmetric key using a classical
        computer, and thus the concern for conveying higher-strength
        keys begins to lose its allure.

Can we make a reference to said opinion?  Without that, this looks like
argument from authority (and an anonymous one at that).

===

Additional comments from incoming ART AD, Orie Steele:

Section 1.4

Prefer to see the exact base64 format cited (not base64url, with or without
padding , etc...)

...

I assume normative terminology in the model itself, does not contradict the
RFCs from which it is derived?

> "A private key and, optionally, its associated public key.
>  Implementations SHOULD ensure that the two keys, when both
>  are specified, are a matching pair.";

Why not MUST?

> "A private/public key pair and an associated certificate.
>  Implementations SHOULD assert that the certificate contains
>  the matching public key.";

Why not MUST?

> "A private/public key pair and a list of associated
> certificates.  Implementations SHOULD assert that
> certificates contain the matching public key.";

Why not MUST?

> 3.3. Unconstrained Public Key Usage

This seems not great. later...

> whereby associated certificates may constrain the usage of the public key
according to local policy.
...
> whereby configured certificates (e.g., identity certificates) may constrain
the use of the public key according to local policy.

Why is this not a SHOULD / MUST ?

> 3.5. Strength of Keys Conveyed

it might be better to convert this to a recommendation, with MUST NOT / SHOULD
NOT, etc...

> Implementations SHOULD only use secure transport protocols meeting local
policy.

Why not MUST ?

> This module defines storage for cleartext key values that SHOULD be zeroized
when deleted, so as to prevent the remnants of their persisted storage
locations from being analyzed in any meaningful way.

Nice to see this recommendation.