More feedback on draft-igoe-secsh-x509v3-01

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

Sections 4 and 5 seem a little bit strange to me.  After rereading
them a couple of times, I'm still not sure that they actually
clarify anything and they might confuse things.

RFC 4253, Section 8, makes it pretty clear (I think) that
what ever is sent as "server public host key and certificates"
is K_S.  Similarly, RFC 4252 is pretty clear that the the
publickey blob can contain certificates.

In section 4, not only do we not list all of the possible
key exchange packets (we missed out listing the kexgss
packet and of course any future kex methods) but
we seemingly loosen up the requirements by saying
"an enconding of the data structure..."

I think both of these sections might be collapsed into
one that reads something like:

  The publickey algorithms and encodings defined in this
  document SHOULD be accepted anyplace in the ssh2
  protocol suite where publickeys are used, including,
  but not limited to hostkeys, publickey authentication
  and hostbased authentication.

  Where such a publickey is included in the dataset which
  is input to a hash algorithm, the exact bytes that are
  transmitted on the wire must be used as input to the
  hash functions.  In particular, implementations MUST NOT
  omit any of the chain certificates or OCSP responses
  that were included on the wire, nor change encoding
  of the certificate or OCSP data.  Otherwise hashes that
  are meant to be computed in parallel by both peers will
  have differing values.

In Section 7, IANA Considerations, do we need to mention
the oids defined in section 2.1.2?  It looks like the
arc used isn't under iana's control (Did I read that
correctly?), so perhaps not.

Thanks,

Joseph