[Bug 2389] New: update the PROTOCOL.certkeys spec to avoid confusion regarding encoding of critical options fields

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2389

            Bug ID: 2389
           Summary: update the PROTOCOL.certkeys spec to avoid confusion
                    regarding encoding of critical options fields
           Product: Portable OpenSSH
           Version: 6.8p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: Documentation
          Assignee: unassigned-bugs at mindrot.org
          Reporter: dsavints at gmail.com

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.