Bug 2389

Summary:	update the PROTOCOL.certkeys spec to avoid confusion regarding encoding of critical options fields
Product:	Portable OpenSSH	Reporter:	Dmitry S. <dsavints>
Component:	Documentation	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	NEW ---
Severity:	enhancement
Priority:	P5
Version:	6.8p1
Hardware:	All
OS:	All

Description Dmitry S. 2015-04-24 18:27:57 AEST

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.

Comment 1 Dmitry S. 2015-04-24 23:40:39 AEST

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.