Re: draft-ietf-secsh-publickeyfile is stuck

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

I believe I have addressed Russ's and your comments now.

Thanks,

Joseph

Jacob Nevins wrote:
> 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/
>