Re: [netconf] crypto-types fallback strategy

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

Hi Kent,

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


The authors are looking for clear direction for the next update to the draft(s).

>From the gist of the discussion, the punch list appears to be:

- revert back to using identities, as they were in the -08 revision.
- only define base identities for what's needed immediately for TLS and SSH and keystore key-encryption.
- define these base identities in distinct YANG modules
- have each identity's description statement indicate what the binary key data is encoded.
[RW]
I think that this matches my view, except for "define these base identities in distinct YANG modules".  I don't feel particularly strongly about this, but I was thinking that the base identities would still be defined in crypto-types.yang, which might help keep the import references simple.


A bit separate from the above, but still in mind:

  - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure
  - specify that all SSH public-keys are a "ssh-public-key-type" type (see below)
  - specify that all encrypted symmetric keys are a DER-encoded OneSymmetricKey structure
  - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure

The "ssh-public-key" type would be defined as:

     typedef ssh-public-key-type {
         type binary;
         mandatory true;
         description
           "The binary public key data for this SSH key, as
            specified by RFC 4253, Section 6.6, i.e.:

              string    certificate or public key format
                        identifier
              byte[n]   key/certificate data.";
         reference
           "RFC 4253: The Secure Shell (SSH) Transport
                      Layer Protocol";
          }

Any concerns?
[RW]
I think that this sounds OK.

Minor: Does the "string" in the description above mean "ASCII string" or "binary string", RFC 4251 seemingly uses both definitions?

Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously the right thing to do?  Are there other choices?

Thanks,
Rob


Kent // author