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

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.

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

--- Comment #1 from Dmitry Savintsev <dsavints at gmail.com> ---
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.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Added this text:

The name field identifies the option. The data field contains
option-specific information encoded as zero or more values inside
the string. I.e. an empty data field would be encoded as a zero-
length string (00 00 00 00), and data field that holds a single
string value "a" would be encoded as (00 00 00 05 00 00 00 01 65).

All options are "critical"; if an implementation does not recognise
a option, then the validating party should refuse to accept the
certificate.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.