Re: [netconf] FIXMEs in ietf-crypto-types and client/server models

[Kent Watsen <[e-mail]>]

Hi Henk,


> Under the assumption that the trust stores will be used for TLS (maybe potential other things), I am not sure if the YANG module is an appropriate place to make some (maybe implicit?) "mandatory-to-implement" decisions. If there can be (and I think effectively there should be, but I do not know the appropriate place for them) prescriptive statements here, I would recommend the following proposals for the use with TLS:

I understand the sentiment expressed, but the details are muddy.  I presume the below are the clarifications, but even they are not clear to me...   ;^)


> 1.) With respect to the format of the "raw" pub-key, I propose that the structure defined in section 3 of RFC 7250 MUST be used.

Is this what you have in mind?

OLD:

  typedef raw-public-key {
    type binary;
    description
      "The binary key data for a raw public key.
       FIXME: specify how it is formatted.";
  }

NEW:

  typedef raw-public-key {
    type binary;
    description
      "A SubjectPublicKeyInfo structure, as specified in RFC
       5280, encoded using ASN.1 distinguished encoding rules
       (DER), as specified in ITU-T X.690.";
    reference
      "RFC 7250:
         Using Raw Public Keys in Transport Layer Security
         (TLS) and Datagram Transport Layer Security (DTLS).
       RFC 5280:
         Internet X.509 Public Key Infrastructure Certificate
         and Certificate Revocation List (CRL) Profile.
       ITU-T X.690:
         Information technology - ASN.1 encoding rules:
         Specification of Basic Encoding Rules (BER),
         Canonical Encoding Rules (CER) and Distinguished
         Encoding Rules (DER).";
  }

If so, then I think Balazs's idea to use ks:local-or-keystore-asymmetric-key-grouping is a good one, as it ultimately becomes a SubjectPublicKeyInfo structure for the public-half, and a one of a few different kinds of structures for the private half. 



> 2.) With respect to cipher suite and interoperability, I propose to make RFC 7151 and RFC 4492 (basically the NIST curve and its format extensions) mti for raw pub-key and to point to RFC 7250 for guidance & to make RFC6635 mti for psk.

Can you propose the draft-text you have in mind?


> 3.) With respect to key identities, I propose that raw pub-key identities as specified in RFC 6920 and a minimum hash length enabled by mode sha-256-120 MUST be used & to support and recommend the use of Identity Hints (section 5.2. in RFC 4279) for PSKs and refer to the corresponding security considerations (section 7 in RFC 4279).

Can you propose the draft-text you have in mind?


> My first question - on a technical level: do these proposals in the context of using TLS sound reasonable to the group?

This is hard to answer without the understanding the change to the YANG module


> My second question - on a semantic level: do these normative requirements belong here?

You mean in the YANG module?  Where else might they be located?


> My third question - on a noob level :) If they belong here, where would these mandatory requirements be spelled out?

In the YANG modules, we strive to define as much normative information as possible using YANG statements for automation but, when necessary, resort to "description" statements to define things.  But I think you know this already, so maybe you're asking a different question?


> Viele Grüße,
> 
> Henk

PS: all the above regards RPKs, but how should PSK be defined?

OLD:

 typedef psk {
    type binary;
    description
      "The binary key data for a PSK (pairwise-symmetric or
       pre-shared key).  FIXME: specify how it is formmated.";
  }

NEW:

  ???

Is there any reason to not use a presumed ks:local-or-keystore-symmetric-key-grouping, that would ultimately become either an OctetString or a OneSymmetricKey?




Kent // contributor