You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If no certification paths satisfy either extension, the subscriber MAY return a handshake_failure alert
An alternative would be to mandate that the subscriber always needs to respond with some certificate and its trust anchors as described in §4.3. What is the advantage of the former? There is a clear disadvantage: a client might actually support a trust anchor that the subscriber has available, but it might not have sent it, due to size or privacy constraints.
The text was updated successfully, but these errors were encountered:
Sending something requires an explicit choice of fallback certificate somewhere, and the server might not have configured one. The intention was that, whether you send a handshake_failure or a certificate, the EncryptedExtensions message still comes in and triggers the retry.
The intention was that, whether you send a handshake_failure or a certificate, the EncryptedExtensions message still comes in and triggers the retry.
That intention would work. I don't see that in the text now, and I could imagine an implementor just failing early with handshake_failure without sending EncryptedExtensions.
Sending something requires an explicit choice of fallback certificate somewhere, and the server might not have configured one.
When would this happen? That means the server also doesn't know what to send if the client doesn't send any trust anchors.
That intention would work. I don't see that in the text now, and I could imagine an implementor just failing early with handshake_failure without sending EncryptedExtensions.
Hmm. I went to write this down, but it's actually kinda tricky. In fact the natural way to implement this in BoringSSL would actually fail to send EncryptedExtensions because we don't proceed with the handshake until we know which credential we're acting as.
This may require some more thought. Or perhaps we end up with #53 and it doesn't matter. Or maybe we just say you really gotta pick a fallback credential. (Provided you have some credential that satisfies sigalgs and other rules. If you don't, a fatal error without retry is fine because no trust anchors would have worked anyway.)
An alternative would be to mandate that the subscriber always needs to respond with some certificate and its trust anchors as described in §4.3. What is the advantage of the former? There is a clear disadvantage: a client might actually support a trust anchor that the subscriber has available, but it might not have sent it, due to size or privacy constraints.
The text was updated successfully, but these errors were encountered: