2.2.4 Clarify AUTH data format

[ciseng]

On January 1, 2020, Jim wrote: 2.2.4 - I am having a problem with trying to parse the content of the AUTH property.  I have no problems with 2.2.4.3 because this is a zero length sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token (possibly binary with no length prefix) followed by an optional binary cryptographic value.  For introspection, I would need to figure out the length of the token before I could make a guess at the length of the cryptographic value.  However given that there is no divider this does not seem possible.  This may also become a problem for the response from the client in the event that there is a change from an 8-byte nonce to a variable length one.

CS, January 14: Not specified a  format, because I  thought we discarded the variable-length nonce idea based on the meeting in Singapore, and the two pieces of information can be extracted when using fixed length. What would you suggest - introduce a specific format?length_of_token+binary data for token+(the rest is cryptographic value)?

[jimsch]

For the 8-byte nonce, this can be ignored if you really believe that nobody is going to complain about the length of the value being authenticated. Not an huge issue.

For the other cases I think you need to introduce a format which is length prefixed for the token so that the field can be parsed. Even for a text token, trying to count curly braces is going to be painful.

[ciseng]

Added clarification on the binary data in MQTT is represented by a two-byte integer length, which indicates the number of data bytes, followed by that number of bytes. so the authentication data is length prefixed; so total_length + the data; I separated the data further like this for 2.2.4.1 For this option, the Authentication Data MUST contain the two-byte integer token length, the token, and the keyed message digest (MAC) or the Client signature. For 2.2.4.2: The Authentication Data in the Client's response is formatted as client nonce length, the client nonce, and the signature or MAC computed over the RS nonce concatenated with the client nonce.

[jimsch]

You section numbers are wrong, but the content is correct. I still need to implement but I think this solves my problems.

[ciseng]

Corrected section numbers in my comment - the correct text was added to the correct sections in the profile document.

[jimsch]

Looks to be in the source file. Are you getting the CI to run when you check things in?

[ciseng]

I typically follow the steps in https://github.com/martinthomson/i-d-template/blob/master/doc/REPO.md manually. If there are discrepancies, I must have had an issue with make gh-pages, which I have not noticed. Will aim to fix today.

[ciseng]

OK - I remembered why I did not use Travis or Circle (both complain about permissions for different reasons). I deployed pages again manually through gh-pages. Things should be up-to-date now.

[jimsch]

Ok - Circle-CI is setup and running