Subject: Re: [pkix] Possible OCSP Extensions

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 19 Mar 2012 16:35:00 -0400

There are two separate questions, first which protocol to change,
second how to implement the change.

I look at protocols as being carriers for information interchanges
between sets of parties rather than being conduits for a specific type
of information. So if we have a protocol that is being used for
communications between client application set X and the set of service
parties Y, I think it should be capable of covering all such
communications.

Now one outcome from this particular discussion is that for the first
time we appear to have arrived at a distinction between OCSP and SCVP
in terms of the services that they involve and thus an actual reason
for having two separate protocols.

Namely a given client application is going to make use of one SCVP
service for all certificates but checking revocation status means a
logical connection to multiple OCSP services (one per CA).

The only exception to that rule would be if a client used a local OCSP
service as a proxy fanning out queries to the various backend services
in which case OCSP starts to look very much like SCVP.

SCVP is intrinsically a protocol for delegating PKI related work and
to perform its function needs to have a superset of OCSP capabilities.
It is a different protocol from OCSP and the consumer is always a
client that has a specific trust relationship with the specific
service.

The only connection between the two is that an SCVP service is going
to need to make OCSP lookups to perform its function. There is no way
for the SCVP service to return NOT-ISSUED unless the authoritative
service can return NOT-ISSUED.

So:

OCSP is a protocol for publishing authoritative information
SCVP is a protocol for delegating PKI processing tasks

NOT-ISSUED is a new type of authoritative information and so extending
OCSP is appropriate.

On the question of how to implement, OCSP or CRL whitelists (CWLs?), I
think the answer probably needs to be 'both'. There are so many parts
of PKI processing that assume interchangeability, it might not be a
good idea to do one without the other anyway.

And expressing positive trust rather than negative trust is of course
going to mean that we can't rely on the certificate serial number
alone as identification in either case. We are going to need a digest
or the like.

So my current proposals are:

To support issuer transparency (aka not-issued)
1a) Extension into OCSP for NOT-ISSUED using serial # ranges
1b) Extension into OCSP to specify certificate by digest
1c) Extension to CRLs to specify 'this is a complete whitelist for
serial range X thru Y' and cert by digest

Together with a requirement to return NOT-ISSUED for non existent
certs rather than REVOKED or UNKNOWN, these extensions permit an
external party to determine if a CA is in compliance (by making
queries for random serials, hashes and checking response) or has lost
control of their HSM (returns NOT-ISSUED for an observed cert).

Separately I have proposals for:

2) Publish security policy 'SSL always offered' (via DNS, HTTP)
3) Publish security policy 'OCSP always stapled' (via the cert)
4) Combine all the client side flows of type 'client to trusted
service' into efficient calls to a single broker, this would subsume
DNS, SCVP and Kerberos into one simple UDP call.

On Mon, Mar 19, 2012 at 12:03 PM, Stephen Kent <[email-masked]> wrote:
>
> At 8:55 AM -0400 3/16/12, Phillip Hallam-Baker wrote:
>
> On Wed, Mar 14, 2012 at 4:47 PM, Stephen Kent <[email-masked]> wrote:
>> At 2:13 PM -0400 3/14/12, Phillip Hallam-Baker wrote:
>>
>> Does anyone use SCVP?
>>
>>
>> I'll let others, who know better than I, respond to this question.
>>
>> If there is going to be a choice between maintaining OCSP and
>> maintaining SCVP then OCSP is going to be the one that I choose.
>>
>>
>> If the proposal is to keep the name OCSP and add a lot of functionality
>> that overlaps SCVP, that is not a reasonable course of action.
>
> OCSP is the Online Certificate Status Protocol. This is Certificate
> Status. So if we accept your argument that there is overlap with SCVP,
> the fault is with SCVP.
>
>
> Not true. OCSP is a sloppy shorthand name or a protocol that reports the
> revocation status of a cert, as noted in RFC 2560:
>
> 2.  Protocol Overview
>    In lieu of or as a supplement to checking against a periodic CRL, it
>    may be necessary to obtain timely information regarding the
>    revocation status of a certificate (cf. [RFC2459], Section 3.3).
>
> This is a minor incremental development of the protocol to address a
> functionality that was originally intended.
>
>
>> I didn't suggest abandoning OCSP in favor of SCVP. OCSP provides an
>> alternative (to CRLs) for checking the revocation status of a cert. If we
>> have good reasons
>> to improve on that function, then doing so using OCSP makes sense.
>
> You suggested that the existence of SCVP means we cannot add new
> features to OCSP.
>
>
> I suggested that if a new OCSP feature is already present in SCVP, then
> we ought not add that feature to OCSP. That statement should be interpreted
> by the context in which each protocol is intended to operate. So, if the
> (not well articulated) problem space being addressed is public CAs, vs.
> enterprise CAs, then SCVP is not an appropriate alternative.
>
> I said that I don't accept that as virtually nobody uses SCVP. So if
> you want to push that idea I think it is time to move SCVP to HISTORIC
>
> and slim down the stack a little.
>
>
> I'll interpret this statement as a rhetorical gimmick on your part, as it
> does not merit being treated as a serious proposal.
>
> ...
>
>
> The functionality is certificate status and SCVP is totally
> irrelevant. SCVP does not address this subject area and no public CA
>
> uses it.
>
>
> I agree that SCVP is not an appropriate protocol for public CA cert status
> checking. But, since you've not provided a good description of the problem
> that you want to solve with a change to OCSP, you didn't rule out SCVP.
> Subsequent list traffic shows that some folks are interpreting your proposal
> in an enterprise context, which is where there is a direct conflict with an
> extant PKIX standard.
>
> OCSP has an extension mechanism. It should have been used to implement
>
> SCVP in the first place.
>
>
> You are entitled to that belief, but the WG did not agree. We went through
> a long, fair process to decide how to proceed, and SCVP was the winner.  The
> fact that your pick didn't win then is not a basis for trying to reclassify
> SCVP as historic.
>
> In subsequent messages directed to other folks you said that a goal is "...
> enable a re-engineering of CA architecture so that we eliminate 'single
> break' systems."  That's a noble goal, but if it is also a big topic, not
> one that we address with a change to OCSP. Agsin, we lack an adequate
> description of the problem to be solved.
>
>
>
> Steve

-- 
Website: http://hallambaker.com/

---

From: brennan security <[email-masked]>
Date: Mon, 19 Mar 2012 17:29:28 -0400

PHB,

Rereading SCVP, while keeping in mind Steve Kent's discussion of
applicability of enterprise vs public validation response capabilities
and your previous comments on the relative impacts of a "not issued"
vice "unknown", I see SCVP as just as vulnerable.

SCVP appears to be slightly more resilient to a "CA/hsm compromise and
certificates with duplicate serial production" (RFC 5055 4.9.1 &
4.9.2), but it seems just as vulnerable to "CA/HSM compromise and
novel certs".  If anyone can point out in the RFC how this is wrong,
I'm all ears.  However, due to the inapplicability of SCVP to public
implementations, I don't see it as a viable solution, instead, I see
interdependence.

Consequently, I second your current proposals of 1a, 1b, 1c.

Furthermore, I propose:
1d: Extension to SCVP to cover 1a, 1b & 1c (RFC 5055) - any updates to
OCSP should likewise benefit SCVP.

-b

On Mon, Mar 19, 2012 at 4:35 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 20 Mar 2012 12:13:16 +0000

> second how to implement the change.

Three.  First is "Is a protocol change needed?"

-- T

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Mar 2012 10:31:09 -0400

>Three.  First is "Is a protocol change needed?"

Thanks, Tim. The first question we need to address is the one you noted,
based on a written description of the problem to be solved.

Steve