Re: [netconf] crypto-types fallback strategy

[Schönwälder, Jürgen <[e-mail]>]

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>