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

From: Joseph Galbraith <[email-masked]>
Date: Wed, 31 Mar 2010 18:54:40 -0600

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:

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.

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

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

o The self-signed certificate specifying the root authority MEY be
  omitted.  All other certificates in the chain up to the root
  authority MUST be included.

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.

Is there a need for more than one OCSP response per issuer?
Would it make more sense to do:

        uint32    certificate-count
          string    certificate
          string    ocsp-response-from-certificate-issuer
	  [1..certificate-count]

Use a 0 length string if no OCSP response is available.

I'm not sure whether this is a good idea or if I'm just
showing my ignorance.

Thanks,

Joseph

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 31 Mar 2010 21:41:31 -0500

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

>   because the verifier is not able to build a chain to a trusted

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

> real life use case or not.)

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

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

> the OCSP responses included to have anything to do with the

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