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

[Nicolas Williams <[e-mail]>]

On Thu, Aug 05, 2010 at 04:17:57AM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > 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.
> 
> And if you have a fancy bridged CA, you will likely have the requirement
> to add and maintain your own RootCA cert(s) into the trust anchor stores of
> an of-the-shelf software/browser anyway, so you should be able to
> use the exact same mechanism to push all necessary bridgeCAs
> to your clients entirely obviating the need for AIA-cert-downloads.

Does a TLS extension exist now by which clients and servers can provide
each other those hints?  What if there are multiple paths to a trust
anchor and the best path is not the one your peer hinted?

I'm not sure that AIA can be avoided entirely.  I'd like to hear more
about that.  But what I can tell that prompting the user about whether
to follow a cert's AIA is not practical nor useful (except in a debug
tool).  Also, if AIA can't be avoided then note that if AIA URLs are
sufficiently constrained then the harm they can cause can be limited,
and that when SCVP is used such harm can be further limited.

Nico
--