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

[Martin Rex <[e-mail]>]

Miller, Timothy J. wrote:
> 
> 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.

The TLS architecture requires a server to send the client a complete
certificate chain, omitting at most the self-signed root certificate,
and it permits clients to perform certificate path validation only
on the server-supplied chain.

There currently is a proposal for having the server provide 
OCSP responses for not just his own end entity cert, but also
for all intermediate CA certs so that the client does not
have to go chasing down certificate revocation information.

If you look at the certificate path validation algorithm as it
is described in rfc-5280, it is _NOT_ allowed to parallelize
the OCSP requests for a certificate chain during path validation
(in case you're using the AIA-information to locate the OCSP responder),
but instead, for security, you need to validate the certificate
individually and sequentially from the trust anchor down to the
end entity cert to determine wether a certificate is trusted,
before you use any information from such a peer-supplied cert
to perform public key crypto operations or access network resources
described in the unverified cert (AIA-OCSP or CRL-DPs).

n.    attributes check
      signature verification
      revocation check
n+1.  attributes check
      signature verification
      revocation check
n+2 ...


So in order to make the facility to have the server provide all
OCSP responses necessary for the revocation checking in the client's
certificate path validation work efficiently and reliably, the client
should hint the server about its trust anchors whenever the server
has multiple certificate chains to choose from for the server
Certificate handshake message.

There is also no problem when the network resouces that the
entity performing the certificate path validation queries,
are preconfigured or pre-trusted, instead of being arbitrary
creations of a potential attacker.  And a RootCA that contemplates
bridging with other PKIs should definitely set up a repository
for bridge CA certificate and could list that in its own trust
anchor certificate.  That would allow certificate and trust anchor
managment in a pull / update-on-demand style.


-Martin