Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-yang-model-10: (with DISCUSS and COMMENT)

[Mahesh Jethanandani <[e-mail]>]

Hi Ben,

There was one AI on my plate to get back to you on. See below.

In addition, I had sent my responses to the remaining comments. Let me know if you are good with them.

> On Aug 4, 2021, at 11:34 AM, Mahesh Jethanandani <[e-mail]> wrote:
> 
>>> 
>>> 
>>>> 
>>>> There's also a few places where we didn't quite clean up all the fallout
>>>> from switching from enumerations to identities (for MAC and
>>>> DTLS-adjacent algorithms), that really ought to get fixed before
>>>> publication.  I try to note them in the COMMENT.
>>>> 
>>>> I also think we need to be a bit more specific about the structure of
>>>> the (binary) private-key leaf/values provided when a certificate entry
>>>> is created.  Ideally this would just be by reference to some other spec,
>>>> but the situation is unfortunately messy.  (It doesn't help that we
>>>> allow DTLS 1.2, which allows certificates that are used for key-exchange
>>>> as opposed to signing, and those are not terribly mainstream.)  We may
>>>> need to pull in some other experts to figure out the right way to write
>>>> about this.
>>> 
>>> Ok. The way I am reading this is that we need to wait to hear more from the experts that you cite before making any changes.
>>> 
>>> Note, in WG discussion the ask was for the format of the private-key to be binary. I am not an expert, but would it help if the description said something about using PEM format for the private-key?
>> 
>> I think binary is probably fine; a PEM encoding is just base64 encoding and
>> sometimes a little bit of a hint as to what the contained structure is.
>> But my recollection is that the PEM type indication for certificate private
>> keys is not always precise enough to indicate what is to be used, so an
>> implementation would need to consult the "type" sibling leaf anyway in
>> order to process the "private-key"...but it's not entirely clear that just
>> "type" is enough information on its own.
>> 
>> It is possible that we can find the necessary references without pulling in
>> an external expert, but if we get stuck I would probably ask Russ Housley
>> or Sean Turner for help.
>> 
>> As a starting point, I note that RFC 4211 lists several Private Key
>> structures in Section 4.2.2 in ASN.1 syntax.  We would presumably require
>> that the binary value exposed by the YANG module be the DER-encoded version
>> of that ASN.1 structure.  RFC 5915 has a private-key structure for ECC
>> keys.  The complications then come in specifying how the other YANG
>> elements determine which (DER-encoded) ASN.1 structure is used for the
>> "private-key" contents.  In particular, "dtls-cert-type" indicates only a
>> "certificate type" in the TLS sense -- X.509, raw public key, and the like.
>> Both X.509 certificates and raw public keys can use keys from different
>> cryptosystems or cryptographic algorithms.  So I find it pretty
>> inescapable that we'll need some in-band signaling about whether the
>> private-key is a basic RSA key, or perhaps an RSA-PSS key that has some
>> specific associated parameters, vs a DH or DSA key, or ECDH, ECDSA, EdDSA,
>> etc.  With in-band signaling comes the need for a table or enumeration of
>> what the different (currently supported) key structures are.  It seems that
>> draft-ietf-netconf-crypto-types may have a start at private-key structures
>> of this sort, though I have not been following that work closely (it seems
>> to be in WGLC at the moment).
>> 
> 
> We will need to go back to the WG to discuss this. Let us get back to you on this.
> 

This is what I proposed to the WG to resolve this issue, and did not receive any objection. Let me know if you are ok with it.

We would like to introduce a new leaf called ‘algorithm’ which is a identity reference to one of the ‘private-key-formats’ defined in ietf-crypto-types module, that will identify the type of algorithm used to encode the private key. That module identifies three algorithms, RSA, EC, and One Asymmetric. The change will look something like this:

+
+          leaf algorithm {
+            nacm:default-deny-write;
+            type identityref {
+              base ct:private-key-format;
+            }
+            mandatory true;
+            description
+              "Identifies the algorithm identity with which the
+               private-key has been encoded. This value can only be
+               provided when this instance is created, and is not
+               subsequently writable.";
+          }

The second, and this was my an oversight on my part, are lines which I have introduced new as part of the model to protect any data that we do not want either read or subsequently written; or read at all. In particular, the private key within a cert is now protected by ‘default-deny-all’, per RFC 8341. Similarly, nodes that were identified as “This value can only be provided when this instance is created, and is not subsequently writeable” in the Babel Information Model, are now protected by the flag ‘default-deny-write’ from RFC 8341. There are four instances of this flag in the model, including the one in the above addition. 

Thanks.

Mahesh Jethanandani
[e-mail]