Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

Hi Martin,


>>> I guess it is still needed
>>> when a key is generated though.  But then note that "rsaEncryption" is
>>> not an OID ("1.2.840.113549.1.1.1" is the OID).  If you want to use a
>>> symbolic name you need something else.
>> 
>> Isn't it?  Check https://tools.ietf.org/html/rfc3279#section-2.3.1
>> <https://tools.ietf.org/html/rfc3279#section-2.3.1>.
> 
> The symbolic name is not (guaranteed to be) globally unique.

Probably...



>>> Is the idea that the module becomes ietf-tls-keystore with top-level
>>> node tls-keystore?
>> 
>> There is no need to change the "keystore" module's name.
> 
> So where would keys for SSH go?  Your reasoning was (which I agree
> with) don't create a super-generic module for all things crypto /
> keys, but let's focus on what we need (you wrote "to configure an
> HTTPS server).  If we limit ourselves to TLS it should be reflected in
> the naming.   But perhaps I misunderstood your intention.

Some options:

1) use a 'union' between the two key types (binary vs string)
2) add a new 'case' to the "private-key" choice called "ssh-key"
3) go back to -04 draft with top-level "host-keys" container

Of these, (2) is the obvious choice. 



> Right, but at that time the idea was to be able to have very generic
> "algorithm", and have each alg define its own format, right?  As soon
> as we limit "algorithm" and the format for the key, we are no longer
> generic.  Hence we should have a less generic name, that more
> precisely decribe what it is.

s/ ietf-crypto-types / ietf-asn1-types /?




>> More fully, that line says: 
>> 
>> 	c) figure out a plan for SSH later (the risk level is pretty low,
>> 	e.g., I've seen code to key SSH keys from TLS keys)
>> 
>> The intention was to signal that it should be easy to determine how to
>> support SSH, to support the netconf-client-server draft.  Nothing is
>> blocked.  We just need to discuss a plan for what to do.  The easiest
>> thing would be to 1) update the mapping table in the ssh-client-server
>> drafts from mapping SSH-specific algorithm identifiers (e.g., in
>> rfc4253) to OIDs
> 
> But do these OIDs exist already?

Probably.  Regardless, we have to map them to something.  Look at ssh-client-server draft.



>>> Yes, NC/RC are programmatic APIs, but simplicity is always goodness...
>> 
>> ACK, but let's be clear that the "simplicity" is in the ready access
>> to tooling, not from an algorithmic perspective.
> 
> But the solution becomes more robust if you can use the format you're
> used to w/o additional conversion.

Right, see option (2) above.



Kent