Re: [netconf] crypto-types and keystore comments

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 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

Ok.  This is worth exploring imo.

> 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.

My point is really just that a single global list like this is not
sufficient.   It doesn't matter if "feature" has problems; a single
global config false list is not sufficient for what you're trying to
do.

> >> 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.

But that would be different key-format identities, right?  The issue
here is about what the specfic format is for ssh-public-key-format.
The format I suggest is also already used in RFC 7317, as was pointed
out before by someone else.


> 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

Do you have a pointer to this?

> , hence the exploration.  As for complexity, how do we know
> until we try?

I think we _are_ trying now...


/martin



> >>> 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
> 
>