[saag] Re: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer

Hi, Thi,

Yes, also agree that an internet draft would be better to describe what the Secure Internet is and how it works.

Technically, it is hard for me to understand what a Live Key is in cryptographic essence. Say, still a normal private key associated with an explicilit or implicit public key? Detailed description and some examples may need.

Also, if one user u1 in the domain of identity provider idP1 would like to communictate u2 in the domain of idP2, how can they establish trust between them as u1 may not trust idP2 and u2 may not trust idP1.

Finally, it seems that the proposal heavily relies on hardware. So, how can applications without secure hardware assumptions run securely?

Cheers,

Guilin


发件人：Thi Nguyen-Huu <[email protected]<mailto:[email protected]>>
收件人：Eric Rescorla <[email protected]<mailto:[email protected]>>;saag <[email protected]<mailto:[email protected]>>
抄 送：saag <[email protected]<mailto:[email protected]>>;Sergei Nikitin <[email protected]<mailto:[email protected]>>
时 间：2025-08-19 17:37:34
主 题：[saag] Re: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer

Dear SAAG members,
I’m writing to follow up on my earlier outreach regarding The Secure Internet architecture. After further reflection and community feedback, I believe this initiative is best introduced through a BOF (Birds of a Feather) session rather than a standalone Internet-Draft.

The Secure Internet (SI) enables what legacy architectures deemed infeasible — and what users have long dreamed of:

  *   No user action: No passwords, no MFA, no friction.
  *   Protocol-native protection: Cryptographic defense against session hijacking and adversary-in-the-middle (AitM) attacks.

SI proposes a new trust model for the Internet — one that replaces static credentials and certificate-based authentication with policy-bound cryptographic keys anchored in hardware, available only when organizational trust conditions are met. This enables non-interactive, mutual authentication via mTLS without certificates, transforming how endpoints and services establish trust.
Given the architectural scope — spanning transport security, endpoint identity, and trust enforcement — SI does not fit neatly into existing working groups. It introduces foundational concepts such as:

  *   Live Key: A dynamic identity signal tied to verified user presence and device integrity.
  *   LIM/TIM (The Identity Machine): A system that governs Live Key availability based on policy.
  *   MagicEndpoint: A trusted channel between endpoint and IdP, enabling continuous identity signaling.
I believe a BOF is the right venue to:

  *   Explore the feasibility of a new working group
  *   Discuss technical foundations and deployment models
  *   Align with existing standards (TLS, FIDO2, RATS)
  *   Define a roadmap for multiple RFCs under the Secure Internet umbrella
I’ve sent to [email protected]<mailto:[email protected]> and [email protected]<mailto:[email protected]> a BOF proposal and use cases and would welcome your guidance on next steps. I’m also happy to coordinate with other interested parties to organize the session and seed discussion with initial drafts.
Thank you for your time and consideration. I look forward to your thoughts.

Warm regards,
Thi Nguyen-Huu
Proposer and Lead Architect of The Secure Internet
CEO, WinMagic Inc.
[email protected]<mailto:[email protected]>

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
[email protected]<mailto:[email protected]> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:[email protected]]<http://www.facebook.com/WinMagicInc>  [cid:[email protected]] <https://twitter.com/winmagic>   [cid:[email protected]] <http://www.linkedin.com/company/winmagic>   [cid:[email protected]] <https://www.winmagic.com/blog/>
[A person holding a phone and typing on a computer  AI-generated content may be incorrect.]<https://winmagic.com/en/secure_internet/>

From: Eric Rescorla <[email protected]>
Sent: Friday, August 15, 2025 4:22 PM
To: Thi Nguyen-Huu <[email protected]>
Cc: StJohns, Michael <[email protected]>; Salz, Rich <[email protected]>; [email protected]; Paul Wouters <[email protected]>; Sergei Nikitin <[email protected]>
Subject: Re: [saag] Re: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer


You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Hi,

If you want this to be considered by the IETF, a good start would be to submit an internet-draft with the specific proposal you have in mind.

-Ekr


On Fri, Aug 15, 2025 at 7:54 AM Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> wrote:
Thanks, Michael and Rich.

Sorry we did not do this before. Please see if this is good. Thanks.
---

IPR Holder: Thi Nguyen-Huu
Document(s): Letter_Secure_Internet_IETF_W3C.docx (and any revisions)
And attached the revised Letter_Secure_Internet_IETF_W3C_5.pdf


Patent Information:
The IPR holder is not aware of any patent or patent application that covers or may cover the technology described in the above-referenced document.

Additional Notes:
This declaration is made in good faith in accordance with the IETF IPR policy defined in RFC 8179.

Submitted by: Thi Nguyen-Huu, CEO of WinMagic Corporation
Date: 11 August 2025

Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
[email protected]<mailto:[email protected]> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
[cid:[email protected]]<http://www.facebook.com/WinMagicInc>  [cid:[email protected]] <https://twitter.com/winmagic>   [cid:[email protected]] <http://www.linkedin.com/company/winmagic>   [cid:[email protected]] <https://www.winmagic.com/blog/>
[A person holding a phone and typing on a computer    AI-generated content may be incorrect.]<https://winmagic.com/en/secure_internet/>

From: StJohns, Michael <[email protected]<mailto:[email protected]>>
Sent: Wednesday, August 13, 2025 1:06 PM
To: Thi Nguyen-Huu <[email protected]<mailto:[email protected]>>
Cc: Paul Wouters <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Sergei Nikitin <[email protected]<mailto:[email protected]>>
Subject: Re: [saag] Re: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer


You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Hi - it would be helpful if you could make an IPR declaration similar to what the IETF uses for its documents, but by email. The amount of encumbrance will play heavily into whether this gets any traction with the IETF community.

Thanks - Mike



On Wed, Aug 13, 2025 at 09:56 Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> wrote:
Thank you, Paul.


  1.  I am replying and add [email protected]<mailto:[email protected]>. I will resend to [email protected]<mailto:[email protected]> as well. Thanks.


  1.  Just a comment: our idea to eventually omit the certificate can be an option for the future. It’s not essential for the Live Key and mTLS.


Cheers

Thi Nguyen-Huu | CEO

Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
[email protected]<mailto:[email protected]> <https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>
Toronto, ON<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  |<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  M9W 4Y8 |<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  Canada<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,%0D%0A+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g> | www.winmagic.com<http://www.winmagic.com/>
[cid:[email protected]]<http://www.facebook.com/WinMagicInc>  [cid:[email protected]] <https://twitter.com/winmagic>   [cid:[email protected]] <http://www.linkedin.com/company/winmagic>   [cid:[email protected]] <https://www.winmagic.com/blog/>
[A person holding a phone and typing on a computer    AI-generated content may be incorrect.]<https://winmagic.com/en/secure_internet/>

From: Paul Wouters <[email protected]<mailto:[email protected]>>
Sent: Tuesday, August 12, 2025 12:39 PM
To: Thi Nguyen-Huu <[email protected]<mailto:[email protected]>>
Subject: Re: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer


You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.


Hi Thi,

The Security Area Directors were forwarded this email.

Begin forwarded message:

From: "Thi Nguyen-Huu via RT" <[email protected]<mailto:[email protected]>>
Subject: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer
Date: August 11, 2025 at 3:51:53 PM PDT



Subject: Proposal for Discussion: The Secure Internet – Embedding Trust into the Protocol Layer



Dear IETF and W3C Working Group Members,



I’m writing to propose a discussion around a new architectural model we call The Secure Internet—a vision that reimagines how identity and trust are established online by embedding them directly into the transport layer.
the appropriate venue to discuss such items would be the SAAG mailing list of the IETF.


At the core of this model is a cryptographic identity signal called the Live Key, derived from the user presence, security posture and anchored in TPM hardware. This signal is long-lived, non-exportable, and accessible only when specific security conditions are met—such as active user’s OS login, full disk encryption, and up-to-date system patches. These conditions are policy-defined, allowing organizations to enforce dynamic, context-aware trust requirements beyond simple user presence.

Furthermore, the Live Key enables mutual TLS (mTLS) without requiring client-side certificates.
you will likely run into big resistance for the significant privacy risks associated with this proposal. but as I said, the proper discussion venue within the IETF for this would be the SAAG mailing list.

Paul, on behalf of the SEC Area Directors





Instead, the client registers its Live Key directly with the server, similar to the FIDO model. This simplifies trust establishment, eliminates the need for certificate authorities, and enables personalized, cryptographically assured sessions.

The Secure Internet aligns with the goals of both TLS and WebAuthn/FIDO2:

  *   It complements mTLS by enabling certificate-less client authentication.
  *   It enhances FIDO2 and Passkeys by offering a transport-level trust mechanism that can eliminate user interaction and additional policy-defined signals check while maintaining strong assurance.
  *   It inherently satisfies and exceeds NIST FAL3-level assurance without tokens, or channel binding. The architecture can eliminate the need for federated authentication entirely. In this model, the identity provider (IdP) evolves into a real-time, CA-like trust authority—capable of informing the relying party (service provider) when a previously registered public key is no longer trusted.

Importantly, this model does not require changes to existing standards—at least not initially. It builds on them, offering a new way to express identity and trust natively within the protocol layer. In the future, optional client certificates may be considered as part of evolving standards. We believe this approach could be of interest to working groups focused on TLS, OAuth, WebAuthn, and identity federation.

We would welcome the opportunity to present this concept, share open specifications, and explore how it might align with ongoing efforts across both IETF and W3C.

Thank you for your consideration.



PS. The same text is in the attachment. And for more info on our website please visit: https://winmagic.com/en/secure_internet/



Sincerely,



Thi Nguyen-Huu | CEO



Tel: +1 905.502.7000 x 3288  |  Toll Free: 888.879.5879
[email protected]<mailto:[email protected]> <https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g> |  www.winmagic.com<http://www.winmagic.com/>



WinMagic Corp. | 11-80 Galaxy Blvd.<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>

Toronto, ON<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  |<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  M9W 4Y8 |<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g>  Canada<https://www.google.com/maps/search/80+Galaxy+Blvd.+%0D%0A+Toronto,+ON+%7C+M9W+4Y8+%7C+Canada?entry=gmail&source=g> | www.winmagic.com<http://www.winmagic.com/>
[cid:[email protected]]


[cid:[email protected]]


[cid:[email protected]]


[cid:[email protected]]
[cid:[email protected]]



_______________________________________________
saag mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
saag mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
saag mailing list -- [email protected]
To unsubscribe send an email to [email protected]