Ion Larranaga Azcue <ila...@s21sec.com> writes: >I don't think it's necessary going to that degree of detail. For your >specific first example, alert the alert "bad_certificate" is enough
We already have error codes at about that level. They're not enough to debug any problems (I mean, "bad certificate" is only marginally better than the canonical Ken Thompson Unix error message in which a giant "?" lights up in front of you, "the experienced TLS developer will usually know what's wrong"), thus the need for free-form text messages that tell you what the actual problem is. >The problem I see with it is that it's hard for applications to automatically >parse it, Applications don't need to parse it, it's an optional, opt-in debugging/diagnostic facility to help developers sort out why a handshake is failing, not something that an application is meant to process. >I would first start trying to define an extended error reporting protocol >using only numeric codes Please, go ahead and do so. For that we'll probably need to start a new list to allow everyone to debate at length which error codes are needed and what they should represent. tls-error-bikeshedd...@ietf.org seems to be a good candidate name. Either that or say it's a UTF-8 string with free-form text, and we'll assume developers can somehow manage to figure the rest out themselves, as they have for pretty much every other situation in which free-form text error messages are used. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
