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

[Nicolas Williams <[e-mail]>]

On Thu, Aug 05, 2010 at 03:03:15AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > On Thu, Aug 05, 2010 at 01:07:22AM +0200, Martin Rex wrote:
> > > Yngve N. Pettersen wrote:
> > > > The kind of crafted URLs you are concerned about can also be injected by  
> > > > way of OCSP and CRL URLs, and OCSP is AFAICT actually supported by more  
> > > > clients than AIA CA.
> > > 
> > > That is incorrect.  The path validation algorithm checks cryptographic
> > > correctness and certificate (attribute) validity starting at a trust
> > > anchor first, and ONLY when that succeeds, CRLs and OCSP is checked.
> > 
> > That's true of path _validation_.  It's not necessarily true of path
> > _construction_ (see RFC4158).  That is, if you start with an EE cert you
> > might have to go find the intermediate CA certs.
> 
> I don't know rfc4158, but I don't see how a standardization level
> should marginalize a severe security problem.  The TLS renegotation
> problem was not less severe by working-as-specified and being
> commonly implemented in the installed base.  :-/

FYI, RFC4158 is Informational.  But surely you can see that it's easier
to build validation paths from the ee cert to a trust anchor than it is
to do it the opposite way.  If you don't want to use AIA then you need a
directory where you can find the intermediate CA certs.  But for a
sufficiently large/complex PKI that might require keeping a large
databse in sync across many orgs, that is, not trivial.

The point is that using AIA is simpler than not.  In traditional PKIs,
and with your peer sending you their cert chain, (see below) there
should be no need to use AIA.

What can be done to improve the AIA situation is to constraint AIA URLs
such that, for example, they cannot specify arbitrary port numbers, and
to very few URL schemes (HTTP and LDAP should suffice).  Yes, this means
you could cause a relying party to attempt an HTTP GET from or LDAP
search on random servers.  As you say, the best option is to have the
peer send you a cert chain that you can validate from the root to the EE
cert (that way you're never following untrusted URLs).  But will your
peers be able to do that if you have a complex PKI?

> And I see a big difference in a user trying to manually and
> interatively construct a certification path and consciously deciding
> to include individual, not necessarily pre-trusted sources of
> information -- as long as it is not possible for an attacker to entice
> this construction to perform accesses to arbitrary resources without
> limits and entirely without critical consent and interaction of the
> entity doing the path construction.

I would like to agree about interaction, but... what's the user to do
with a prompt about whether to follow a given AIA URL??  They're only
going to answer "yes".

One option might be to implement SCVP (RFC5055) -- SCVP servers can
cache path consturction results effectively enough to minimize the
impact of AIA attacks.

> > If you're building a path from the target to the anchor then you'll
> > probably want to prune paths as soon as possible by validating
> > intermediate CA certs as soon as possible.
> 
> Validating in the form of pruning "expired" or otherwise clearly
> inappropriate certs based on "cheap" plausibility checks on certificate
> attributes?  Maybe to a limited extent.  Public key crypto operation
> with untrusted keying material or even worse, network access based
> on URIs from untrusted sources -- certainly not without explicit
> user/operator confirmation!

The whole point is to establish trust by establishing a path to a
trust anchor.  Eventually you'll know if the EE cert and the
intermediate CA certs are valid, or that the EE cert is not valid, or
that no valid path can be constructed, or that some intermediate CA
cert is invalid (if you're constructing a path then you'll stop when you
find an invalid intermediate CA cert and run out of path construction
options).

> For the case of TLS, however, it has always been a clear requirement
> for each communication peer to build and send one own's certificate
> in a complete and corretly ordered sequence, optionially omitting
> at most the self-signed root certificate at the end of that chain.

If you have a non-traditional PKI then the path sent by the peer may
only be partially helpful.  (Though in that case you probably won't be
using AIA but instead searching a directory or configuration.)

> So really, a server with a certificate from a fancy briged CA should
> definitely, similar to the "server name indication" get a TLS
> ClientHello extension defined and have the client provide hints
> about the trust anchors if the server is unable to send a certificate
> chain acceptable to the client's certificate path validation
> algorithm as-is without such information.

Yes.

Nico
--