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.

Let's see.  The pain point is the access of a network
resource based on information under full control of a
potential attacker.  We definitely need to get rid of that entirely.

The environment where this happens is complex PKIs with
cross-certificate / bridgeCAs.

I think it would be just fair to burden that CA from one's own
original certificate chain which engages in cross-certification
activities with the burden to provide any missing cross-certs
to *ALL* other trusted PKIs accessible through cross-certification.

When going up your own certificate chain, there is also a much
higher likelyhood for the existence of contractual liabilities
and a much higher likelyhood of accessibility to online resources
from that CA.


Patching up a rough list of requirements:

1. Require the CA in your own original certification path 
   which engages in cross-certification to offer/distribute
   *ALL* cross-certs to other PKIs.

2. Define a download service to be offered by that CA where
   a client can send a list of Issue DNames and/or AuthorityKeyIdentifiers
   from all issuers of an incomplete cert chain that may be completable
   through cross-certs into the callers original chain for the retrieval
   of the missing cross-cert(s) (optionally plus
   intermediate certs from the callers own chain).

3. Define an AIA-style declaration for accessing that service in
   in at least one of the certs between the cross-certification
   engaging CA and the end entity cert that wants to perform
   a secure kind of certification path discovery.
   Multiple alternative URIs is OK.  But the important part is
   being able to send a list of issuer DNames and/or authorityKeyIdentifers
   to which the missing cross-cert(s) are needed for a certificate
   path validation.  Providing an option to request OCSP responses
   for the cross-certificates along with the missing certs might
   be sensible.

4. Support a similar out-of-band configuration for the location of
   that cross-cert provisioning service.


If you only ever have to query pre-known locations for missing
cross-certs, then this is *MUCH* easier to configure (including
firewall traversals / filtering rules), more reliable, easier
to check and maintain, better accessible (performance-wise),
its much easier to define acceptable timeouts, and you know
whom to call if it doesn't work.

-Martin