Re: [TLS] [pkix] New version of Multiple OCSP mode of Certificate

[Nicolas Williams <[e-mail]>]

On Thu, Aug 05, 2010 at 08:39:33AM -0400, Miller, Timothy J. wrote:
> You have yet to propose an alternative.  Absent an alternative, I'd
> support a security note to the effect that path construction modules
> should be careful to treat retrieved data as potentially unsafe until
> validated.

You were responding to Martin, but I'll take a crack at this too, based
on Martin's idea for using "hints":

 - Define hints that peers can tell each other about what PKI / what
   part of a PKI they "live in";

    - this could take the form of a name, domainname, whatever (requires
      naming conventions)
    - or it could take the form of a list of trust anchor names (can be
      quite large, so not ideal)

   I prefer using names to listing TAs.  To prevent namespace collisions
   I'd use domainames to name PKIs.

 - Given a peer's hints send a full cert chain that they should be able
   to verify;

 - Then the peer will validate the cert chain you send them from the
   trust anchor to your EE cert.

This takes the onus of path construction from the rp's shoulders (where
it is dangerous to the rp) and puts it on the rp's peer (where it
belongs).  Validation path construction is not elided completely, just
moved to where it belongs.

Alternatively, and even concurrently, I'd like to constraint AIA as I've
described before and which I'll repeat here:

 - AIA URLs should be limited to HTTP an LDAP schemes only;
 - The server name must be a domainname, to be resolved to an IP
   address;
 - The local part of AIA HTTP URLs should be left empty because it will
   be well-known (see host-meta);
 - The local part of AIA LDAP URLs should be left empty because there
   will be a simple convention for searching the DIT (try a well-defined
   scope sub search from each naming context provided by the server);

This is still not entirely safe because an rp's peer can still cause you
to try to retrieve a CA cert from any hostname they want.

Alternatively, and even concurrently:

 - Replace AIA with a URL construction convention based on the
   certificate's issuer's Name.

This last is still not entirely safe if you're constructing a path from
a peer's EE cert to any of your TAs because the peer's EE cert's issuer
can be anything they want it to be.

Nico
--