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

[Douglas Stebila <douglas%stebila.ca@localhost>]

On 2010-Mar-31, at 2:58 AM, Joseph Galbraith wrote:

> 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.

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]

>  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.

This is a good point.

> 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.

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