Re: draft-ietf-secsh-publickeyfile is stuck

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

Sam Hartman writes:
> we are waiting for text to clear Russ's discuss comment.

which appears to be as follows:

| Section 3.4 says:
| >
| > The body of a public key file consists of the public key blob as
| > described in [I-D.ietf-secsh-transport], section 4.6, ...
| >
| There is no section 4.6 in the referenced document.  I assume that
| this should be a reference to section 6.6.

(referring now to RFC 4253)
I agree.

| The examples in section 3.6 do not seem to match the key blob
| description in [I-D.ietf-secsh-transport], section 6.6, which says:
| >
| > The key type MUST always be explicitly known (from algorithm
| > negotiation or some other source).  It is not normally included in
| > the key blob.
| >
| But in this context, it is needed.  This document should make this
| clear with a MUST statement.  Note that it is included in each of
| the examples.  I base64 decoded them and checked.

There was a suggestion back in October that the above paragraph was
misleading and should be stricken from the transport draft. However,
nothing happened, and now it's in RFC 4253 so we'll have to live with
it.

I think the root cause of the confusion is that the term "blob" is
poorly defined. publickeyfile says (section 3.4):

: The body of a public key file consists of the public key blob as
: described in [I-D.ietf-secsh-transport], section 4.6 [...]

but the relevant section (6.6 as discussed above) does not define the
term "public key blob" anywhere. It defines the encoding as

:       string    certificate or public key format identifier
:       byte[n]   key/certificate data

In the absence of indications otherwise, I would have thought that
"public key blob" referred to just the byte[n], not the format
identifier -- especially as in the later definitions of signature
formats, "blob" is defined that way.

However, from the publickeyfile examples and existing practice, it is
clearly intended that the publickeyfile body includes the format
identifier.

Sections 3.4 and 4 of publickeyfile should be amended to make this
clear. I think that will address Russ' comment.


(A further comment on RFC 4253 sec 6.6 -- rather late, I know:

: The certificate part may be a zero length string, but a public key is
: required.  This is the public key that will be used for
: authentication.  The certificate sequence contained in the
: certificate blob can be used to provide authorization.

What is the "certificate part" referred to here? In the "ssh-rsa" and
"ssh-dss" formats, I see no certificate, and no zero-length string
replacing it.

Going back through the list archives suggests that the first sentence
has long been considered buggy. Oh well.)


Further suggestions for publickeyfile-10, not related to Russ' DISCUSS:

Neither the document title nor the abstract mention that this document
defines a standard textual representation for public key fingerprints.
This makes it harder than it could be to discover where the
fingerprint format is defined.

I suggest the following paragraph be added to the Abstract:

   In addition, this document defines a standard textual
   representation for SSH public key fingerprints.

2 (Introduction): typo:
|    This document describes a mechanism for creating a short text string
|    that that uniquely represents a particular public key, called
          ^^^^^
Remove duplicate "that".

3.2.2 (Comment Header): typo:

|    existing implementations fail if these quotation marks are omitted
                                                                       ^
Add full stop at end of sentence.

3.3.3 (New Headers): typo, imprecise text, IANA:

|    New headers that are of the from "x-" are considered experimental,
                                 ^^^^
|    and may be used without IETF consensus.

Suggested replacement text:

   Headers with header-tags beginning with "x-" are considered
   experimental, and may be used without IETF consensus.

|    All other headers are reserved for use only by IETF consensus.

Doesn't this imply the existence of an IANA registry, contrary to what
section 5 "IANA Considerations" says?

3.5 (Differences with RFC1421 PEM formats): typos:
|    Implemetors should take care to notice that while the format is
     ^^^^^^^^^^^
s/Implemetors/Implementers/

|    o  The other specifications use different BEGIN/END delimeters (five
                                                         ^^^^^^^^^^
s/delimeters/delimiters/