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

[Martin Rex <[e-mail]>]

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

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.


While the relative ordering of 6.1.3 a1, a2, a3 makes a lot of sense
security-wise, I'm confused to see a4 as the last check instead of
the first(!) one.  Comparison of the issuer field should be a memcmp()
on a ASN.1 DER encoded DName, and it looks odd to suggest doing a likely
expensive public key operation before a trivial memcmp() without
a rationale (I can not currently think of a rationale for this).

http://tools.ietf.org/html/rfc5280#section-6.1.3


> 
> > So when doing path validation correctly, you never access untrusted
> > CRL and OCSP resources.
> 
> 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!

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


-Martin