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

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

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.

-- Tim

>-----Original Message-----
>From: Martin Rex [mailto:[e-mail]]
>Sent: Wednesday, August 04, 2010 8:03 PM
>To: Nicolas Williams
>Cc: [e-mail]; [e-mail]; [e-mail]; Miller, Timothy J.;
>[e-mail]
>Subject: Re: [TLS] [pkix] New version of Multiple OCSP mode of
>Certificate
>
>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