Hi! This message closes out the 3rd WGLC for draft-ietf-tls-exported-authenticators. I have created GH issues for the two issues raised during WGLC: https://github.com/tlswg/tls-exported-authenticator/issues/62 https://github.com/tlswg/tls-exported-authenticator/issues/63 Once addressed, and assuming the changes are not large, we will progress this draft towards our AD.
I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D needed awaiting resolution of the two issues. spt (for the chairs) > On Jun 5, 2020, at 07:29, Watson Ladd <watsonbl...@gmail.com> wrote: > > On Thu, Jun 4, 2020 at 9:48 PM Sean Turner <s...@sn3rd.com> wrote: >> >> Another reminder ... >> >>> On May 22, 2020, at 09:23, Sean Turner <s...@sn3rd.com> wrote: >>> >>> This is the 3rd WGLC for "Exported Authenticators in TLS" draft available >>> at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. >>> The secdir review during IETF LC raised some issues and as a result there >>> have been a couple of new versions. Please respond to the list with any >>> comments by 2359 UTC on 8 June 2020. > > I've implemented earlier drafts. I do have a concern with the > validate API as presented in the draft: it treats empty authenticators > as valid, and then returns the identity as a certificate chain that > must be validated by the application. Similar APIs have lead to easily > foreseeable pwnage. Instead I would recommend the validate API carry > out X509 validation against a trust store or validation function and > treat the empty authenticator as invalid. That way someone has to > think before not checking the certificate returned. > > Sincerely, > Watson Ladd _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
