See http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-April/033849.html and http://lists.mindrot.org/pipermail/openssh-unix-dev/2015-April/033844.html for background. Damien wrote in his response: "Maybe the wording of PROTOCOL.certkeys could be improved to avoid the confusion" Currently http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?rev=HEAD describes the format of the critical options field as a sequence of zero or more tuples: string name string data which may mislead readers into thinking that since both fields have the same type (string), they should have the same encoding (also based on the encoding of multiple other string fields in the specification) - while in the reality "data" is a composite field that happens to contain (or wrap) a string. It would be desirable to reword the specification (maybe introduce a different type like "object" or "container"?) to highlight the fact that the data field requires special treatment (double length prefix). This would help authors' of alternative implementations guided by the specification to preserve interoperability with SSH.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.9&content-type=text/x-cvsweb-markup would be a better and more stable reference to the version of the specification in question.