[Plants] Re: draft-burls-mtac-00: applying the MTC issuance model to a non-TLS subject

[Thom Wiggers <[e-mail]>]

Hello Dick,

Opaque identifiers are directly in conflict with the scope of this working group (failing the transparency requirements). You have also repeatedly been warned to keep messages on topic. 

Please refrain from advertising this work any more work on this list that is not in scope for this working group.

Regards,

Thom Wiggers
PLANTS WG Chair

> Op 23 jul 2026, om 15:22 heeft Dick Brooks <[e-mail]> het volgende geschreven:
> 
> This message is to support the use of opaque identifiers outside of, and in addition to X.509 certificates, to enable Zero Trust verification.
>  
> Zero Trust identities, like ztdnaid, are intentionally opaque to prevent leakage of personal information. X.509 certificates, by their nature, contain verifiable identity information.
>  
> An opaque cyberspace unique identifier, such as ztdnaid, sits outside of an X.509 certificate as an identifier that can be checked for trustworthiness in a Zero Trust verification before performing any processing, including login credential and X.509 certificate processing.
>  
> This is how my company is implementing Zero Trust identifiers with ztdnaids within our ZTBouncer Gateway products. There is no access to a backend resource until trust has been verified using a ztdnaid lookup in a Public Trust Infrastructure (PTI) Trust Registry.
>  
> Adoption of Public Trust Infrastructure (PTI) Trust Registries is gaining momentum thanks to Google’s Transparency Ledger, Microsoft’s SCITT ledger (RFC 9943) and ETSI’s  List of Trusted Entities (LoTE)  ETSI TS 119 602;  the backbone of the EUDI Wallet trust infrastructure
>  
> I use an airport analogy to explain how this opaque ztdnaid is used to verify trust in a Zero Trust interaction before allowing access to a protected resource/application function, like a REST API;
> https://www.linkedin.com/feed/update/urn:li:activity:7457528519401742336/
>  
>  
> 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/
>  
>  
> From: Thom Wiggers <[e-mail]> 
> Sent: Thursday, July 23, 2026 5:11 AM
> To: Reuben Burls <[e-mail]>
> Cc: [e-mail]; Brendon Nosworthy <[e-mail]>
> Subject: [Plants] Re: draft-burls-mtac-00: applying the MTC issuance model to a non-TLS subject
>  
> Hi Reuben,
> 
> 
>> Op 22 jul 2026, om 12:49 heeft Reuben Burls <[e-mail] <mailto:[e-mail]>> het volgende geschreven:
>>  
>> MTAC leaves carry agent identity fields rather than TLS certificate fields
> 
>  
> Apologies for not reading your whole draft yet, but can you maybe explain why you can’t just shove your identity into X.509 certificates or -extensions? I feel that “we need to carry different strings” should be an orthogonal issue to the trust and transparency system that is MTC — it should not require a different mechanism, though perhaps different payloads.
>  
> Regards,
>  
> Thom