On Sat, 2016-09-17 at 13:01 +0200, Nikos Mavrogiannopoulos wrote: > > ? uint16 10015 // provisional extension ID > > ? uint16 extlen // all extensions have a length of their payload > These you shouldn't normally care about (at least in the gnutls api > if I remember well) Right. In the OpenSSL add_cb() for the custom extension I do actually have to provide the length of the data block I've generated for the payload, of course. But I don't care what it looks like on the wire. > > > > ... then the payload contains what you talked about above... > > ? uint16 entirely_redundant_payload_len_again == extlen-2 > > ????uint16 ident1_len > > ????char "dave" > > ????uint16 ident2-len > > ????char "nikos" > > ????... > right. > > > > > Can we ditch the first uint16 in payload, given that it is entirely > > redundant? Or am I misreading the spec to put it there in the first place, > > and the formal language is supposed to *include* what I called 'extlen' > > According to the protocol tt has to be there. OK, thanks for confirming that. So that brings me to my next question, which is... given that the protocol is just a draft, should we propose *changing* it not to include that redundant length? -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160917/054c39f8/attachment.bin>
