Re: [netconf] crypto-types fallback strategy

[Martin Bjorklund <[e-mail]>]

Kent Watsen <[e-mail]> wrote:
> 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>.

The symbolic name is not (guaranteed to be) globally unique.

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

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

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.

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

But do these OIDs exist already?

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

But the solution becomes more robust if you can use the format you're
used to w/o additional conversion.

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



/martin