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

From: Joseph Galbraith <[email-masked]>
Date: Tue, 30 Mar 2010 10:58:14 -0600

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

---

From: Douglas Stebila <[email-masked]>
Date: Wed, 31 Mar 2010 11:49:10 +1000

>  and hostbased authentication.

Yes, that does seem like a better way of doing it, as apparently we have missed out on a number of existing areas.  However, I would like to be able to list of all the existing areas where we believe it does apply in order to give implementers an idea of what they need to change based on current standards in order to adopt this (i.e., "including but not limited to" type language).  Can you help me put together an exhaustive list of current areas?  I believe they include:
- in the SSH_MSG_USERAUTH_REQUEST message when "publickey" authentication is used [RFC4252]
- in the SSH_MSG_USERAUTH_REQUEST message when "hostbased" authentication is used [RFC4252]
- in the SSH_MSG_KEXDH_REPLY message [RFC4253]
- in the SSH_MSG_KEXRSA_PUBKEY message [RFC4432]
- in the SSH_MSG_KEXGSS_HOSTKEY message [RFC4462]
- in the SSH_MSG_KEX_ECDH_REPLY message [RFC5656]
- in the SSH_MSG_KEX_ECMQV_REPLY message [RFC5656]

>  are meant to be computed in parallel by both peers will

This is a good point.

> correctly?), so perhaps not.

The point of that line in section 7 was to say that IANA does not need to do anything about the OIDs.  Perhaps an unnecessary line, but when it goes through the various formal reviews later in the process they'll tell us to take it out if they think so.

Douglas

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 31 Mar 2010 17:10:15 -0400

--On Wednesday, March 31, 2010 11:49:10 AM +1000 Douglas Stebila 
<[email-masked]> wrote:

> Yes, that does seem like a better way of doing it, as apparently we have
> missed out on a number of existing areas.  However, I would like to be
> able to list of all the existing areas where we believe it does apply in
> order to give implementers an idea of what they need to change based on
> current standards in order to adopt this (i.e., "including but not
> limited to" type language).

Public key algorithms are a fairly straightforward abstraction in the ssh 
protocol, and we defined two of them up front.  Any implementor who doesn't 
already have this abstraction or something like it is beyond our help.  I 
don't think it's necessary or appropriate for every document that defines a 
new <foo> algorithm or method to enumerate all the places where the <foo> 
abstraction is used.