Re: [netconf] crypto-types and keystore comments

[Kent Watsen <[e-mail]>]

Hi Martin,


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

I added FIXME comments into all of ietf-[ssh/tls]-[client/server].



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

True.  But how can we define a way to get a list per instance?  Should there be a "config false" list wherever the "algorithm" node appears (i.e., put the list into the crypto-type groupings having the algorithm 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?  

I think so, yes.

> 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 is the binary encoding for the on-the-wire public key.  Yes, for the binary encoding, this is a great option.  But I thought a goal was to try to use native tool formats when possible.  Not that we want to hardcode to OpenSSH, but `man ssh-keygen`:

     -m key_format
             Specify a key format for the -i (import) or -e (export)
              conversion options.  The supported key formats are:
              ``RFC4716'' (RFC 4716/SSH2 public or private key),
              ``PKCS8'' (PEM PKCS8 public key) or ``PEM'' (PEM
              public key).  The default conversion format is
              ``RFC4716''.  Setting a format of ``PEM'' when
              generating or updating a supported private key
              type will cause the key to be stored in the legacy
              PEM private key format.


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

There was an email from Juergen a few months back.


>> , hence the exploration.  As for complexity, how do we know
>> until we try?
> 
> I think we _are_ trying now...

Fair, but there's yet to be a concrete proposal for how to support, e.g., multi-part PEM encoding and, in particular, how it is distinguished from the PEM encoding of the equivalent CMS.  Presumably it's just another identity, but there maybe more to it...


Kent // contributor