Re: [netconf] crypto-types and keystore comments

[Kent Watsen <[e-mail]>]

Hi Martin,


> Suppose I want to configure a ssh host-key as the server-identity for
> my NETCONF server.  Is the intention that a client can pick either
> "ssh-public-key-format" or "subject-public-key-info-format", and the
> server must support both?

It's assumed that the client would set the public key using "ssh-public-key-format" (per RFC 4716, as that is the only standards-based public key format that `openssh` is able to export).  While it's possible to convert the public key to a SubjectPublicKeyInfo structure, doing so is unlikely.  In either case, the same data is conveyed.

The issue presents itself when configuring the "server-identity" in ietf-ssh-server, whether a local definition or a reference to a key in the keystore.   A "must" expression could be used to constrain the supported key-formats allowed.   Our modules could hardcode this for all implementations or, if wanting to provide flexibility, we could let implementations augment-in their own 'must' expression.



>> Yes, well, this is a known problem (e.g.,
>> https://github.com/netmod-wg/yang-next/issues/82
>> <https://github.com/netmod-wg/yang-next/issues/82>).
> 
> That is quite different.

How so?  Features are effectively opstate lists too and, in both cases, YANG fails to support granular discrimination. 

> You're using a normal config false list for this (which is fine), but
> I don't think you can use a single global list like this.

I don't understand this statement.



>> I will say that the definition above was given because it is the only
>> *standards* based key that `openssh` can output (i.e., `ssh-keygen -e
>> [-m RFC4716] -f <private-key-file>`).
> 
> With my proposal you can take the output of this openssh command and
> copy & paste the base64-encoded data from this output to a YANG node
> using ssh-public-key-format.
> 
> With your proposal you have to copy the entire output, base64 encode
> it *again*, and then copy & paste that result to the YANG node.

Not true or, rather, the intention is to support native encoding formats, including DER vs PEM, and CMS vs multi-part PEM.   That a text-based format is base64 encoded is not an issue and, IMO, a feature as it escaping concerns when the content is placed in an XML or JSON document.



>> That said, if you refer to the link I provided at top, it is my belief
>> that the "key-format" node may be extended to support alternate
>> encodings (e.g., DER vs PEM and, potentially, CMS vs multi-part PEM).
>> To this end, perhaps we could support both the 4716 and 4253 formats.
> 
> Do we really want to go there?  This is already quite complex, and
> having a multitude of optional formats for the same thing may make
> things even more complex, to understand and get right.

Binary formats (e.g., DER) are fundamental, but some raised usability concerns, hence the exploration.  As for complexity, how do we know until we try?



>>> o  subject-public-key-info-format
>>> 
>>> The crypto model has:
>>> 
>>>   identity subject-public-key-info-format {
>>>     base "public-key-format";
>>>     description
>>>       "A SubjectPublicKeyInfo (from RFC 5280).";
>>>   }
>>> 
>>> Should this be "DER encoded"?
>>> 
>>> (this and other defintions have references to RFCs in the
>>> description; they should be moved to proper "reference" statements)
>> 
>> Yes.  I put together these definitions in as a test/protocol to gauge
>> viability with the plan to enhance the definitions if the WG committed
>> to the approach.  I just added some "FIXME" comments to my local copy.
> 
> Ok.

It helps immensely when folks can provide spec-text, either on list or as a pull request.



Kent // contributor