Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

Hi Martin,

> I'm not a security expert so I don't have any input on which ASN.1
> structure to support.
> 
> But it seems to me that in both B1 and B2, the "algorithm" leaf isn't
> really necessary in the config, right?  

The "algorithm" leaf is needed, because a "private-key" itself enough.  The RSAPrivateKey and ECPrivateKey ASN.1 structures contain just the raw key fields (e.g., RSA --> [d, p, q, n,e]).  The two structures do not share a common base type that would presumably identify if the payload is an RSAPrivate key or ECPrivateKey, so the the correct parser can be used.  We could argue that private keys should always come with a public key, in which case we could claim that, for B1, the typing of the private key is done via the typing of the public key.  I don't prefer this approach and, as you say, the same algorithm identifier would have to be passed into the generate-asymmetric-key() and generate-symmetric-key() actions, so having the field in the configuration seems right.


> 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>.



> 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.  ASN.1 is not TLS-specific, it just so happens to be heavily used by TLS.

Already, and for awhile now, the ietf-crypto-types module has defined the private-key and public-key using type "binary" with a description statement saying that how it is parsed is defined by the "algorithm" field.   The description statements even say that the RSAPublicKey/RSAPrivateKey formats are defined in RFC8017 and the EC public/private key formats are defined in rfc5915.  These unnamed formats are actually the same ASN.1 structures mentioned in my OP.   So this was/is sort of been the plan all along.  



>>    c) figure out a plan for SSH later
> 
> Hmm, what does this mean?  That we won't do ietf-netconf-server now?

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, and 2) this could get moved into a section called "Implementation Considerations" that also notes that is an implementation convert between the ASN.1 structures used by, e.g., keystore, and the local SSH implementation (e.g., OpenSSH).



> 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.   

According to [1], the private-key format is identical to OpenSSL's private key format (i.e., it uses RSAPrivateKey/ECPrivateKey, not OneAsymmetricKey or something else).  Thus, the only conversion needed is to/from OpenSSH's public key format.  This does not appear to be hard, e.g., [2] has code showing how to do this using Python.

[1] http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL <http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG,-OpenSsh-and-OpenSSL>
[2] https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ <https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/>



Kent // as author