[netconf] FW: crypto-types fallback strategy

["Salz, Rich" <[e-mail]>]

Jake,

As the author of the draft referenced below, do you care to comment?

The crypto-types document in the netconf WG is undergoing some pretty drastic surgery.


On 9/24/19, 4:50 AM, "tom petch" <[e-mail]> wrote:

    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
    
    _______________________________________________
    netconf mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/netconf