Re: [netconf] crypto-types fallback strategy

[Per Hedeland <[e-mail]>]

On 2019-09-18 23:19, Schönwälder, Jürgen wrote:
> On Wed, Sep 18, 2019 at 10:53:09PM +0200, Per Hedeland wrote:
>> On 2019-09-18 22:29, Schönwälder, Jürgen wrote:
>>> On Wed, Sep 18, 2019 at 10:06:38PM +0200, Martin Bjorklund wrote:
>>>> Kent Watsen <[e-mail]> wrote:
>>>>> [moving Russ and Sean to BCC, per Rich's action]
>>>>>
>>>>>
>>>>>
>>>>>> Minor: Does the string in the description above mean ASCII string
>>>>>> or binary string, RFC 4251 seemingly uses both definitions?
>>>>>
>>>>> I don't know, but this is the language found for the "key-data" leaf
>>>>> in RFC 7317 (i.e., we've been living with this definition for awhile)
>>>>
>>>> So the definition is:
>>>>
>>>>                leaf key-data {
>>>>                  type binary;
>>>>                  mandatory true;
>>>>                  description
>>>>                    "The binary public key data for this SSH key, as
>>>>                     specified by RFC 4253, Section 6.6, i.e.:
>>>>
>>>>                       string    certificate or public key format
>>>>                                 identifier
>>>>                       byte[n]   key/certificate data.";
>>>>
>>>> The textual representation of a binary in YANG is base64 encoded.  As
>>>> it happens, this is exactly the same as OpenSSH uses for its keys.  So
>>>> the open ssh key can be copy/pasted into the NC/RC XML/JSON.
>>>>
>>>
>>> My public ssh keys usually start like this:
>>>
>>>     ssh-rsa AAAA...
>>>
>>> Looking at RFC 4251, it seems to me that 'string' is encoded with a
>>> length prefix, followed by n bytes of key data. This means the start
>>> in hex would be something like this:
>>>
>>>     00 00 00 07 73 73 68 2d 72 73 61
>>>
>>> If I base64 encode this, I won't get what I quoted above.
>>
>> Are you sure? I don't have a handy base64 encoder for "space-separated
>> octets represented as hex numbers", but going in the other direction
>> with the initial part of my public ssh key (ssh-rsa), using the Linux
>> 'base64' command and converting the result to "space-separated octets
>> represented as hex numbers" gives:
>>
>> $ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1
>> 0000000 00 00 00 07 73 73 68 2d 72 73 61 00
>>
>> Seems to agree with what you have.
>>
> 
> Aha. So the 'ssh-rsa ' part in my key file needs to be stripped as it
> is actually redundant (but still its there in my file).

Right, it's in mine too of course - I stripped it without thinking,
but realized after posting that this might be the reason that your
encoding didn't match. (There is also normally a trailing
<user>@<host> after the actual key.)

> In the RFC
> 7317 YANG model, this string seems to go into the 'algorithm'
> leaf. All good and usable.

Yes - and hopefully a server implementing it will reject 'key-data'
input with the leading 'ssh-rsa ' (or any other "key type", which all
seem to include one or more '-') - the '-' is not a valid base64
character (nor is space, but base64 decoders are often "liberal" with
whitespace).

> (I wonder what happens if the two algorithm names do not match, time
>   to run some experiments on my ssh implementation...)

Ditto for a server implementing RFC 7317...

--Per