Re: [netconf] crypto-types fallback strategy

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Kent,

Please see inline …

From: Kent Watsen <[e-mail]>
Sent: 17 September 2019 15:24
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail]; Russ Housley <[e-mail]>; Rifaat Shekh-Yusef <[e-mail]>; Sean Turner <[e-mail]>
Subject: Re: [netconf] crypto-types fallback strategy

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


[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].
[RW]
IANA might be OK, I’m not sure.

My original thought was that if a new security RFC is written then it could hopefully also define a YANG module that defines the new identities related to that security protocol.  But that may well depend on the scope of the RFC.

E.g. looking at say draft-ietf-curdle-ssh-ed25519-ed448-11.txt, that has just been approved by the IESG, it would seem that this could probably just update iana-crypto-ssh-types with some new identities.  But other documents might need to introduce new categories (i.e. new crypto types modules) altogether, which I think is OK.





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.
[RW]
OK, so this is where I am beyond the boundary of my knowledge, and don’t really know how keys are programmatically used, but my hunch is that "This identity indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded RSAPublicKey” sounds like the right option.  I think that we want the keys to be in whatever form applications can most readily use them without having to perform an arbitrary conversion.

Thanks,
Rob



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



Kent // contributor