Re: Still more feedback on draft-igoe-secsh-x509v3-01

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Mar 31, 2010 at 06:54:40PM -0600, Joseph Galbraith wrote:
> In section 2.  X.509 Version 3 Certificates, we have:
> 
> >    o  The self-signed certificate specifying the root authority MAY be
> >       omitted.
> 
> which seems to indicate that all certificates except the self-signed
> certificate at the root MUST be included.
> 
> I'm not sure that's what we want (or if that was actually what was
> intended.)
> 
> I think it would be better to say:

SSHv2 key exchange is not retriable, and there's not much room for
negotiating trust anchors (what server cert to present to some client?).
Not sending a chain that the client needs will mean having to reconnect,
which is really obnoxious.

In practice servers will mostly have a single cert per-hostname (at most
one per-interface, including virtual interfaces).  Even then, the
certification path used by the server may not be one the client can
validate, but at least the client should then be able to build its own
certification path for the server's cert.

There are probably going to be many implementations that are unable to
build certification paths.  Therefore it's crucial to at least have the
option to send certificate chains.

> o The chain encoded MAY be incomplete; it is usually not
>   necessary to include the self-signed certificate specifying
>   the root authority.
> 
>   It is NOT REQUIRED to specify any certificates other than
>   the senders certificate.  If the verifier has a trust anchor
>   that is not the self signed root, these other certificates may
>   not be needed.  However, omitting certificates from the chain
>   may make it more likely that certificate verification will fail
>   because the verifier is not able to build a chain to a trusted
>   anchor.

We need to RECOMMEND sending the full chain (excluding the signer's TA).

> I'm worried in particular that there might be cases where the
> signer doesn't have all the certificates necessary to chain
> to the root easily available.  (I'm not sure if this is a
> real life use case or not.)

That's OK.  The relying party should then know how to build
certification paths.

> If we do decide we want to REQUIRE all the certificates, I think
> we should change the paragraph referenced to make that clear:

Either REQUIRE or RECOMMEND, or make sending of cert chains optional.

For userauth making the sending of cert chains optional is easy.  For
host authentication it's harder.

> Also, is there any correlation between certificates and OSCP
> responses?  Currently, there is nothing that constrains
> the OCSP responses included to have anything to do with the
> certificate.

I think just sending an OCSP Response for the EE cert should suffice.
The OCSP Responses for the certs in the certificate validation path can
be cached by peers, proxies.  But if that's not likely, then yes, we
should want to send one OCSP response per cert in the chain being sent.

Nico
--