On Thu, Apr 30, 2026 at 11:18:17PM -0700, [email protected] wrote:
> Internet-Draft draft-ietf-tls-trust-anchor-ids-04.txt is now available. It is
> a work item of the Transport Layer Security (TLS) WG of the IETF.
> 
>    Title:   TLS Trust Anchor Identifiers
>    Authors: Bob Beck
>             David Benjamin
>             Devon O'Brien
>             Kyle Nekritz
>    Name:    draft-ietf-tls-trust-anchor-ids-04.txt
>    Pages:   34
>    Dates:   2026-04-30

The stuff about Authenticating Party Configuration does not look to be
enough.

The issue is how to allow _automated_ addition and removal _non-default_
certificate chains. I think how to do that is non-trivial enough to
discuss.

Trying to automate configuration mechanisms not designed for automation
or altering default chain selection represents unacceptable risk of
breaking stuff. This is critical, as features that break stuff get
disabled very quickly, with no regard for other consequences.

Of course, the concrete mechanisms are AP-specific. What is important is
that those mechansims _exist_, as that is a prerequisite for automated
managment (e.g., ACME) of multiple chains. Futhermore, having chains
that do not participate in default selection is a prerequisite for
deploying TAI on server side at all.



Something along:
------------------------------------------------------------------------
Authenticating parties SHOULD have a separate pool of certificate chains
that are only considered candidates in presence of trust_anchors,
certificate_authorities or similar extensions.

The configuration required to add/remove certificate to/from this pool
MUST be designed for automated editing. E.g., all *.crt files in some
configured directory are considered to be in this pool.
------------------------------------------------------------------------
Probably needs expanding a bit...


In case someone has an another idea for different kind of mechanism to
archive the same goals, that could be added as well.




-Ilari

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

Reply via email to