[Isms] TLS Certificate Path Requirements

[Wes Hardaker <wjhns1 at hardakers.net>]

One question that was not fully flushed out at the last meeting was what
path validation we should require implementations to support.

In particular, we need to decide what a client and a server
MUST/SHOULD/MAY support with respect to what type of path validation
they need to support.  They need to support either or both of:

  - path validation to a trust anchor (e.g. RFC5280 processing)
  - self-signed certificates

Right now the wording in the document doesn't explicitly state what a
implementation must support on either end.  This is roughly what is
spelled out, MIB-and-code-implementation-wise:

  On the client 
    - via the tlstmAddrTable: a finger print of the exact certificate
      expected of the server
    - Words describing that a client may do path validation to a trust
      anchor, but we agreed at the WG meeting that configuration of
      active trust anchors was outside the scope.

  On the server, via the tlstmCertToSNTable:
    - recognizing a cell-signed incoming client certificate via a fingerprint
    - recognizing a fingerprint of a trust anchor that properly
      path-validates [RFC5280] the client's certificate.

So the boiled down questions for this that can be answered in terms of
MUST/SHOULD/MAY:

1) Should the client be required to support self-signed server certificates?

2) Should the client be required to support certificate path validation
   of server certificates.

3) Should the server be required to support self-signed client certificates?

4) Should the server be required to support certificate path validation
   of client certificates.


And an interesting side question:

5) Should we specifically reference RFC5280 as THE path validation
   procedure to use.  The text right now says things like "The client
   MUST always perform appropriate certificate path validation
   procedures (e.g.  [RFC5280]) to ensure the certificate is
   cryptographically valid." where the wording is slightly generic and
   allows for any path validation procedure that the device can perform.
   The fuzziness is there to leave room for future validation documents
   to be used since as long as the validation occurs, I don't think we
   should specifically require 5280.  But that's my personal opinion.

-- 
Wes Hardaker
Cobham Analytic Solutions