Re: [pkix] Revising OCSP

["David A. Cooper" <[e-mail]>]

Matt,

I understand that this thread began with a suggestion to include 
Microsoft's trust model in the update to RFC 2560, but I think the 
working group has already made it quite clear that it is against that.  
So, at this point my only interest is in what the update to RFC 2560 
should say rather than what Microsoft has done or should do in the future.

I think we need to be careful about being overly prescriptive about how 
local configuration is performed on an OCSP client.  Although, it would 
certainly be reasonable to include a statement about this in the 
Security Considerations section.  Here is a paragraph that I found in 
the Security Considerations section of RFC 5280:

    The certification path validation algorithm depends on the certain
    knowledge of the public keys (and other information) about one or
    more trusted CAs.  The decision to trust a CA is an important
    decision as it ultimately determines the trust afforded a
    certificate.  The authenticated distribution of trusted CA public
    keys (usually in the form of a "self-signed" certificate) is a
    security critical out-of-band process that is beyond the scope of
    this specification.

Note that neither of the constraints that you suggest for configuration 
of locally trusted OCSP responders are imposed on path validation trust 
anchors.  The Trust Anchor Management Protocol (draft-ietf-pkix-tamp-08) 
begins with a locally configured Apex Trust Anchor, but there is no 
requirement that a path validation trust anchor be either the Apex Trust 
Anchor itself or that it be signed directly by the Apex Trust Anchor.  
Similarly, most clients do not permit a set of constraints (e.g., 
initial-permitted-subtrees, initial-explicit-policy, 
user-initial-policy-set) to be associated with a trust anchor that must 
be provided as input to the path validation algorithm whenever that 
trust anchor is used.

I think the underlying problem is that the "local configuration" trust 
model is being overused.  Most likely the problem is that issuers that 
have a PKI hierarchy and a single OCSP responder find it difficult to 
implement the CA delegated model.  So the issuers create a situation in 
which client can only accept responses from their OCSP servers using 
local configuration.

Ideally, whenever a OCSP responder is set up by a CA for use by any 
client that is attempting to validate one of the certificate that CA 
issued, the responder would operate as an Integrated or Designated OCSP 
responder.  If this were the case, local configuration would only need 
to be used to accept responses from a locally operated OCSP responder.  
OCSP clients would in most cases be configured to use that local OCSP 
responder to obtain revocation status information for all certificates 
(e.g., as in Appendix D.3 in draft-cooper-pkix-rfc2560bis-00).

Dave

On 07/20/2010 06:46 AM, Matt Cooper wrote:
> Stefan,
>
> I think the local configuration must consist of:
>
> - The specific public key (or cert) of the responder (OR) The specific 
> public key (or cert) of the *direct* issuer of the responder certs.  
> (i.e. This is **not** any root that leads through any number of CAs to 
> any responder)
>
> (***AND***)
>
> - The specific list of CAs for which the specific locally configured 
> responder is trusted to provide status.
>
>
> The second option ("The specific public key (or cert) of the *direct* 
> issuer of the responder certs") is I think no less secure than 
> configuring a specific responder key (or cert) if implemented 
> properly. I would see this implemented as an offline CA. This would 
> provide the ability to re-key your responder(s) without reconfiguring 
> clients. The important thing to recognize here is that this CA must be 
> the DIRECT issuer of the responder certs and I would think the CA 
> should be dedicated to that purpose in this scenario.
>
> Also note the (***AND***) above is just as important as what precedes 
> it. Best I can tell, the Microsoft implementation does not offer that 
> part in any capacity except "Trust to provide revocation status for 
> every CA everywhere" which is apparently the default when I install 
> any new TA.
>
> -Matt