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

[Martin Bjorklund <[e-mail]>]

Hi,

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

So perhaps this is not the best solution?  The big set of types (in
crypto-types) will change over time, and the subsets used in various
applications will also change over time.  The best solution for such
sets in the IETF seems to be IANA registries, with corresponding
IANA-maintained YANG modules.

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

Perhaps we can take a step back and define just the types we need
right now for keystore, in order to finish these drafts.  Then we (or
some other WG) can immediately start to work on an update to
crypto-types that would define more types for other purposes as well.


/martin


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