(+taps) Hi, Thanks for taking a look at that model, Tom. I'll give just a little background:
The current taps-api structure was driven basically by an attempt to support the examples given in the taps-interface draft, for instance in section 5.3.1: https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.1 I didn't do much (or any? don't recall...) of a search for crypto models before throwing together the early ietf-taps-api.yang drafts, including the security config stuff. I mostly worked off the API examples, with intent to look for a more serious answer later as we try to integrate the secure connection support into a reference implementation or 2. What's there now hasn't been through any kind of security review, and I'd characterize it as a placeholder, at the moment. (The taps use of yang is still relatively immature.) I'd be very grateful for a grouping or object of some kind that I could pull in by import from another module, and would support using it in taps-api-yang if we can use it to do what we need (which is to configure connection endpoints to allow secured connections, for either client or server endpoints). I think that would make for a very helpful improvement. Part of the point of using yang in taps was to be able to better exploit yang work from other wgs, and this would be an excellent opportunity to put that into practice, I think. So I would be very delighted to import a model that does this right. Best, Jake On 2019-09-24, 13:02, "Salz, Rich" <[email protected]> wrote: 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" <[email protected]> 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" <[email protected]> To: "Rob Wilton (rwilton)" <[email protected]> Cc: "Russ Housley" <[email protected]>; <[email protected]>; "Sean Turner" <[email protected]>; "Rifaat Shekh-Yusef" <[email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list [email protected] https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
