Re: SSH operations modelled in YANG

Jeffrey Hutzelman <[email protected]> Thu, 26 Jan 2023 08:27:47 -0500
Newsgroups gmane.ietf.secsh
Message-ID <CALF+FNxF_DXKSGfJGBidYqFjHArNmepBhs8sFN3PSdE83naFyQ@mail.gmail.com>
I haven't read the document, but it sounds like the author has just listed
the GSS mechanism OIDs they know about as if they were the only ones that
existed. That's kind of pointless and possibly harmful. It's all well and
good to have a machine-readable form of a registry, as long as it's updated
alongside the real registry. But it's inappropriate to assume and claim
that an open-ended namespace with no registration process contains only the
items the document author happens to know about.

-- Jeff

On Thu, Jan 26, 2023 at 8:12 AM tom petch <[email protected]> wrote:

> From: Jeffrey Hutzelman <[email protected]>
> Sent: 26 January 2023 12:37
>
> > what should IANA do when SSH registers a new GSS KEX
>
> There's no such thing. GSSAPI mechanisms are identified by OIDs, which are
> assigned by the owner of the parent arc.  There is no central registry, and
> certainly not one run by IANA.
>
> SSH can be used with any GSSAPI mechanism that includes the features it
> needs. No registration is required or possible.
>
> The same problem affects other algorithm and method identifiers, too. All
> of these namespaces include provision for privately-assigned names, and
> it's common for algorithms with such names to become widely deployed and
> even considered best practice without any sort of registration.
>
> Jeff
>
> Thanks for the information;  GSSAPI has always been a blind spot for me.
> On the privately-assigned names, yes, those I am familiar with and so is
> the author of this I-D and he explicitly caters for that in the
> instructions to IANA for the maintenance of the modules (but does not say
> anything about the OID, just includes 13 of them in the initial version of
> the YANG module - ah well, IANA will get to see this and decide what they
> understand:-(
>
> Tom Petch
>
> -- Jeff
>
>
>
>