Re: [netconf] I-D Action: draft-ietf-netconf-crypto-types-09.txt

[Kent Watsen <[e-mail]>]

> So, to start with, for each of the types in the crypto module, could
> you specify the link to the corresponding IANA registry?

Yes, please send out the links so we have more clue...



To take a step back, my perception for how we got here is thus:

1) the keystore draft wishes to store keys (perhaps created at the time of manufacturing) that can subsequently be referenced by downstream models, such as in the SSH and TLS client/server drafts.

2) to support this goal, the crypto-types draft defined some types for keys (first as identities, now as enumerations).

3) crypto savvy folks wanted to embrace and extend the definitions in crypto-types to be more complete (i.e., more then just keys)

4) to enable the SSH and TLS models to use types defined in their protocol specs, mapping tables were added to those drafts to map the protocol-specific types to the generic crypto-types type.

5) the IPsec folks now have a similar problem, to which the answer might be to do the same as the SSH and TLS drafts (i.e., define mappings from IPSec-specific types to crypto-types types)

6) the general underlying issue is likely exasperated by the crypto-types draft defining more types than needed for just keys (i.e., the more it tries to support, the more mapping tables are needed), albeit this in itself seems like a good thing.

7) it's unclear to me where the root cause of the problem lies.  It seems that the crypto folks may have instigated this long ago, by creating overlapping definitions for identical algorithms, which then manifested in the form of multiple IANA registries.

8) our efforts to normalize this may be futile, and yet we want to support keystore.

Please correct any misstatements, as I'm speculating on some of the above.

Thinking out of the box, if we were to fold on crypto-types defining algorithms, perhaps keystore could store instances of something like an abstract base class that is subclassed by downstream modules (ssh, tls, ipsec).  The problem with this approach is that the keys become purpose-specific and so, e.g., if a device has a manufacturer-generated key, that key could only be used for the single purpose (e.g., TLS) and not for any other purpose (e.g., SSH, IPSec, etc.).  Sure, the vendor could create key multiple purpose-specific "keys" for the same underlying key store in hardware, but it would ultimately fail to support any purpose, potentially defined later in time.

Kent // contributor