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

["Miller, Timothy J." <[e-mail]>]

>As far as the AIA vulnerability is concerned, you're 0wnd as soon
>as your software connects to the crafted URL in the crafted server
>certificate.  It doesn't matter that whether you discard the reply
>and abort the original browser connection at that point.  If you're
>attacked, that URL is often not going to result in a certificate anyway.

First, real browsers already allow mixed content frames with silent renegotiation *and* late-binding of request authentication, and you're worried about exploiting AIA retrieval?

Second, having identified a problem behavior, what's the fix?  Path discovery is critically important in bridged PKIs, so if chasing AIAs is a Bad Thing, what do we do instead?

>How about warning on first encounter and offer the User to download
>and memorize the intermediate cert -- or to NOT download?

I fail to see how this improves the situation, since we already know users are ill-equipped to make these decisions anyway.  In addition, components without a UI do what?

>As previously described, the certificate path validation algorithm
>specified in rfc-5280 works from the trust anchor downwards to
>the End Entity cert, and will reliably protect you from accessing
>OCSP or CRL information from untrusted/unverified certificates.

Only when the pool used by the PVM contains all the certificates identified in the path.  When the pool is incomplete, or the protocol provides no path (e.g., CMS allows SignedData to elide any and all certificates if the relying party can be expected to have *or discover* them), what does the PVM do?

Failing is "safe" from a security standpoint, but I'd contend that if you put that into a real system it would simply fail to meet any practical definition of the term "functional."

-- Tim