Re: [netconf] crypto-types fallback strategy

[tom petch <[e-mail]>]

Going back a bit, since this is a more generic comment, I get a
different, simpler perspective in
draft-jholland-taps-api-yang
which has me wondering just how complicated this needs to be for it to
be useful in other WGs.

The I-D defines
  identity security-algorithm {description "Base identity for security
algorithms."
  identity cipher-suite { base security-algorithm;description "Base
identity for security cipher suites.";
  identity signature-algorithm {base security-algorithm;
description "Base identity for security signature algorithms.";
  identity ed25519 {base signature-algorithm;
  identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 {
    base cipher-suite;

and

  grouping security-credentials {
    leaf identity { type string;
    leaf trust-ca { type string;
    leaf algorithm { type identityref {base security-algorithm;
    leaf pre-shared-key { type string;
    leaf private-key { type string;
    leaf private-key-callback-handle {type string;
    leaf public-key {type string;

(No SSH but that does not surprise me:-)

Again a more general comment, the IETF often starts simple and adds lots
later, which sometimes goes wrong because no allowance was made for
slotting in extras, but an approach which, I think, more often leads to
successful adoption.

Thus will TAPS consider using
draft-ietf-netconf-crypto-types
or will they RYO?

Tom Petch

----- Original Message -----
From: <Schönwälder>; "Jürgen" <[e-mail]>
To: "Rob Wilton (rwilton)" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>; <[e-mail]>; "Sean
Turner" <[e-mail]>; "Rifaat Shekh-Yusef" <[e-mail]>
Sent: Wednesday, September 18, 2019 5:36 PM

> On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote:
> > >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.
>
> I tend to agree that sometimes less modules is more. For me, the
> problem is likely more that I am not entirely sure what the proper
> base types would be, which may depend on what exactly they are used
> for. I guess I wait until I see the description text...
>
> > 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
>
> I would check what is commonly used in existing configuration
> interfaces. We are not inventing the wheel here. And whatever we
> define better is usable with existing implementations and tools.
>
> > 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";
> >           }
>
> The SSH implementations that I use have the binary key data rendered
> in ASCII. In fact, the whole key record is rendered in ASCII. I
> strongly suggest to use formats that are well established.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf