Hey David, Thanks for the draft! I had some thoughts about how Relying Parties build their list of Trust Anchor IDs to send to the Authenticating Parties. In the draft currently there is different behaviour by the Relying Party depending on whether it is a retry connection or not. When a relying party receives the tls-trust-anchors in the DNS Service Parameter they compute the intersection of the received trust anchors with their configured trust anchors, then they use that information to determine their trust_anchors list - in this case relying parties should offer multiple options. In the other case, when retrying a connection, relying parties should choose a single Trust Anchor ID from the EncryptedExtensions to send. Could you talk me through your reasoning for the different mechanisms? I would suggest using the same mechanism for calculating the trust_anchors on retry as when using the DNS Service Parameter, so the client has consistent behaviour and then the authenticating party has the final choice of the certificate chain to serve. Otherwise, the issue described in Section 5.3 of the draft could occur on retry with the client picking a trust anchor which includes a certificate in the chain it doesn’t support the signature for.
Cheers, Luke
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
