Re: [netconf] crypto-types fallback strategy

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

On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote:
> >From the gist of the discussion, the punch list appears to be:
> 
> - revert back to using identities, as they were in the -08 revision.
> - only define base identities for what's needed immediately for TLS and SSH and keystore key-encryption.
> - define these base identities in distinct YANG modules
> - have each identity's description statement indicate what the binary key data is encoded.
> [RW]
> I think that this matches my view, except for "define these base identities in distinct YANG modules".  I don't feel particularly strongly about this, but I was thinking that the base identities would still be defined in crypto-types.yang, which might help keep the import references simple.

I tend to agree that sometimes less modules is more. For me, the
problem is likely more that I am not entirely sure what the proper
base types would be, which may depend on what exactly they are used
for. I guess I wait until I see the description text...
 
> A bit separate from the above, but still in mind:
> 
>   - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure
>   - specify that all SSH public-keys are a "ssh-public-key-type" type (see below)
>   - specify that all encrypted symmetric keys are a DER-encoded OneSymmetricKey structure
>   - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure

I would check what is commonly used in existing configuration
interfaces. We are not inventing the wheel here. And whatever we
define better is usable with existing implementations and tools.

> The "ssh-public-key" type would be defined as:
> 
>      typedef ssh-public-key-type {
>          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.";
>          reference
>            "RFC 4253: The Secure Shell (SSH) Transport
>                       Layer Protocol";
>           }

The SSH implementations that I use have the binary key data rendered
in ASCII. In fact, the whole key record is rendered in ASCII. I
strongly suggest to use formats that are well established.

/js 

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