Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

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.


/martin




> 
> 
> > Is putting the encrypted keys into DER-encoded OneSymmetricKey
> > obviously the right thing to do?  Are there other choices?
> 
> 
> Yes, if there was one thing that came out of my discussion with Russ
> and Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used
> for encrypting key data.  Anything else would be a BIG effort.
> 
> The real question is if we should also use the One*Key structures for
> unencrypted keys, which could help some ways, but I think that it's
> better to use the values provided by OpenSSL command line.  This
> approach pushes the complexity of using the One*Key structures to just
> the "advanced" case of when encryption is needed and, besides, it
> would primarily be for the NC/RC server to generate/parse; clients
> would rarely encrypt a key themselves, the only case I can think of
> when they might would be for the RMA workflow we discussed a few weeks
> back.
> 
> 
> Kent
> 
>