Hi all, Thanks everyone for a very productive interim! It was nice to see the interest in solving this problem, and to hear from the experiences of folks in the TLS ecosystem. While we client folks may try our best to anticipate the needs of server operators, there’s really no substitute for hearing from you all directly.
We’ve recently published draft-beck-tls-trust-anchor-ids-02: URL: https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-02.txt Status: https://datatracker.ietf.org/doc/draft-beck-tls-trust-anchor-ids/ HTML: https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-02.html It’s been a while since we’d last mailed about this, so I’ll describe the changes since -00: * For convenience, -00 referenced sections of draft-davidben-tls-trust-exprs, as they both targeted the same problem statement. Based on the feedback in Vancouver, we are focusing on draft-beck-tls-trust-anchor-ids and have reworked the document to stand on its own. * We’ve added a bit more discussion under Security Considerations, to further discuss how this work interacts with how PKIs are used in TLS. * We’ve switched the term “subscriber” to “authenticating party”, for the role that presents a certificate. “Subscriber” came from the CA/B Forum Baseline Requirements, where it describes the subscriber or applicant to a CA’s services. While that does identify this role, it is a little odd in a document more focused on the TLS client <-> TLS server relationship than the subscriber <-> CA relationship. We hope these changes will make the draft easier to understand and invite you all to take another look. We think it serves as a good starting point for the working group to build on, and think it is ready to consider for adoption. David, Devon, and Bob
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
