Re: [netconf] crypto-types fallback strategy

[Kent Watsen <[e-mail]>]

Hi Rob (also Rich and Juergen)

> [RW]
> The full numerical OID string is unique, but very hard to be interpreted by a human.  The human readable OID name (e.g. for just the last element) is not unique.
>  
> I agree with Juergen, in that I think that using OIDs as names for encryption protocols is probably a mistake and tying us into the past.

I was somewhat expecting that response ;)  

Fine, now we're aligned to the need to define something for the "algorithm" field.



> [RW]
> Oops, my comment about should have been identities rather than identifiers!
>  
> I think that it is helpful that identities are extensible and can easily be constructed in a modular way.  E.g. defining identities in different YANG modules, and/or putting them under if-feature allows implementations to choose which ones they actually support.
>  
> In ietf-crypto-types I would define the base identities for:
> 
> hash-algorithm, asymmetric-key-algorithm, mac-algorithm, encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, key-exchange-algorithm
>  
> Note, as an aside, I am I also wondering whether the “encryption-and-mac-algorithm” identity should derive from both “mac-algorithm” and “encryption-algorithm”?  Or perhaps it doesn’t need to be defined at all, and the actual identities can just derive from two base identities?
>  
> I then suggest that we put different identities into different YANG modules, perhaps something roughly like:
> Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234)
> Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017)
> Ietf-crypto-elliptic-curve-types for the Elliptic Curve based algorithms (RFC 6090, 5480, 8422)
> Ietf-crypto-mac-types – I’m not really sure how to organize the MAC algorithm types, or even if they need to be defined now.
> Ietf-crypto-aes-types – AES encryption types (RFC 4309)
> Ietf-crypto-ssh-types – das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)
> Ietf-crypto-tls-types – (RFC 8446)
> Ietf-cyprto-dhe-types – Diffier Hellman key exchange (RFC 7919).  Actually, the key-exchanges algorithm types might need to be split up a bit further.
>  
> The key step is that I would say that NETCONF should only standardizes the ones that we need now.  For the others, we could potentially create the YANG modules and either hand this off to the security groups, or work whether them to standardize these through the appropriate WGs.

This is a good path forward: flip back to identities and only define the identities hierarchies needed now.  Having multiple modules make sense (they'd all still be defined in the crypto-types draft).  Only possible discussion point is if these should be "iana-" modules rather than "ietf-" modules?   [The hope being that, if maintained by IANA, it might be possible to get auto-updates].



> 
> Perhaps we can do both, say that the field is parsed according to its "algorithm" value, but for now, all algorithm identifiers happen to point to ASN.1 structures.
> [RW]
> Yes, in essence I think that is what I’m suggesting.

Sounds good.



>  If this is really common, then an identity for “ASN.1 encoded” could also be defined and inherited by crypto type identities above.  I think that this depends on how useful it is to programmatically know that they are encoded in ASN.1

Just knowing that it is ASN.1 encoded isn't enough, unless we say all ASN.1 encoded keys must be a OneSymmetricKey or OneAsymmetricKey (i.e., option 'B2' from before).   Otherwise, the description statement needs to say something like "This identity indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded RSAPublicKey."   Personally, I think this is okay.

An alternative to this may be to use a "choice" statement for "private-key" whereby one of the options is "asn1".



Kent // contributor