[Ssh] Re: Complaint about draft-ietf-sshm-cert

[Dick Brooks <[e-mail]>]

Damien wrote:

> If you're interested in seeing this in SSH, I'd suggest that you start by
implementing this yourself or arranging for someone to do it on your behalf.

The ZTDNAID and Trust Registry concept proposed here is implemented and in
commercial use today.

Information describing an opaque ZTDNAID is found here:
https://www.ietf.org/archive/id/draft-brooks-ztdnaid-new-02.txt

Information about how a Trust Registry is used to verify trust in a ZTDNAID
using a Public Trust Infrastructure (PTI) Trust Registry lookup that returns
a true (trusted) /false (not trusted) result:
https://www.energycentral.com/intelligent-utility/post/a-trust-control-plane
-for-public-trust-infrastructure-pti-t4Li00S02OlbhOu

A ZTDNAID trust verification lookup has similar performance to a DNS lookup.



Thanks,

Dick Brooks
   
Active Member of the CISA Critical Manufacturing Sector, 
Sector Coordinating Council - A Public-Private Partnership
Lifetime IEEE Member, #SBOM SIG member 
https://businesscyberguardian.com/ 


-----Original Message-----
From: Damien Miller <[e-mail]> 
Sent: Friday, July 31, 2026 7:08 PM
To: Dick Brooks <[e-mail]>
Cc: 'Mouse' <[e-mail]>; [e-mail]
Subject: RE: [Ssh] Re: Complaint about draft-ietf-sshm-cert

On Fri, 31 Jul 2026, Dick Brooks wrote:

> Damien,
> 
> Thanks for your suggestion. Please allow me to be precise in what I am 
> requesting the work group to consider:
> 
> Please add a new command line parameter to the ssh client, identified 
> as ZTID with a SHA256 hash value that will be passed in the initial 
> ssh login connection request.

This working group does not specify commandline parameters.

> This will allow a Zero Trust Gateway to intercept the ssh traffic and 
> verify the ZTID as verified as trusted before allowing any ssh traffic to
flow.
> The sshd server can ignore the additional login ZTID parameter.

You've raised this in a conversation about a particular draft[1], but this
request 1) seems to have nothing to do with the draft in question,
2) seems to be ignorant of how the SSH protocol works and 3) ignores what
the WG is explicitly chartered for:

> [...] to update the RFCs documenting SSH to reflect what is 
> implemented and deployed in practice, [...]

If you're interested in seeing this in SSH, I'd suggest that you start by
implementing this yourself or arranging for someone to do it on your behalf.

IMO what you're asking for has nothing to do with the document under
consideration.

-d

[1] https://datatracker.ietf.org/doc/draft-miller-ssh-cert/03/