Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?

From: Ambarish Malpani <[email-masked]>
Date: Fri, 10 Nov 2000 13:42:07 -0800

Here are some of my thoughts on why I think SCVP is the right
way to go ahead with remote path processing (RPP), rather than
creating a new version of OCSP (OCSPv2) and then defining OCSPpath
and OCSPvalid.

Issues with OCSPv2
------------------
- It causes uncertainity and concern about OCSP, even though there
aren't really any problems with the protocol itself
- It will cause a bunch of interoperability issue with OCSP for
certificate status checks, because now you can identify a
certificate in many different ways
- The semantics of what a server is required to do for a plain
OCSP request are unclear - does it need to check the expiry of
the certificate, what about the signature, etc on the cert?
- It is unclear to me that the right thing to do is to change a
stable protocol just to add a bunch of new functionality, that
doesn't really do anything more for the base protocol.
- If we go this route, we will take a lot longer to actually
reach a usable spec for RPP, because our first 12 months will
be spend debating the changes to OCSP
- I would actually like the current OCSP, with some minor
clarifications and changing of the required signature algorithm
to RSA (from DSA), to continue on the standards track, we have
actually had a reasonable amount of interop testing on it

Issues with this approach
-------------------------
- It is very unclear to me that OCSPvalid is trying to do the
same thing as OCSP. So why is there such a strong interest in
doing it as an extension to OCSP - I believe it will actually
cause more confusion than clarification, where when somebody
says they support OCSP and another person wants to use OCSP, there
is no guarantee that they are talking about the same thing.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

---

From: Michael Myers <[email-masked]>
Date: Mon, 13 Nov 2000 13:23:01 -0800

Ambarish:

As a I noted earlier, you need to split out the OCSPv2 draft from the DPV
and DPD drafts.  OCSPv2 simply expands on certificate identification
mechanisms into well-known use cases while preserving backwards
interoperability with existing 2560-compliant implementations.  There's a
few other tweaks but that's the core of it.  I have embedded more specific
comments below.

With respect,

Mike

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, November 10, 2000 1:42 PM
> To: [email-masked] '
> Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
> 
> 
> 
> 

There's no uncertainty that RFC2560 has been approved by PKIX and the IESG.
The only uncertainty is whether or not the WG believes there's sufficient
benefit to have certID (and a few other tweaks) fixed before RFC2560
progresses further down the standards track.

> certificate in many different ways

The thing is, people are doing this already for a variety of reasons, so
OCSPv2 isn't *causing* anything.  Rather, it's responding to well-known
needs.

> the certificate, what about the signature, etc on the cert?

Please clarify if you're speaking to RFC 2560, OCSPv2 or DPV/DPD.

> doesn't really do anything more for the base protocol.

OCSPv2 does not create new functionality.  It standardizes the basis for
additional code development towards delivering 2560-based functionality into
well-known use cases.

> be spend debating the changes to OCSP

SCVP's XML perspective may (should?) take into consideration all the variant
opinions regarding the integration of XML with PKI and ASN.1.  Given the
abundance of recent WG comments, the timeframe is predictably the same
either way.

> actually had a reasonable amount of interop testing on it

It's my intent that the OCSPv2 draft will lead to an informed technical
debate on all issues relevant to RFC2560's transition in status.  Your
preference for RSA as a SHALL vs. DSA as a SHOULD is noted.

> same thing as OCSP.

They're not. DPV proposes a standard extension OID and a corresponding
semantic for use by existing 2560 environments who wish to build into their
existing user base a means for delegated path validation.

> So why is there such a strong interest in
> doing it as an extension to OCSP

Because from a bits-on-the-wire perspective, it's trivial.  It's just an OID
after all, and based on existing hooks in an existing RFC.  Sure,
imlementing on a server the path validation and its corresponding path
discovery process is a pain.  But that's a sunk cost no matter how we go.

But A 2560 server that implements signed requests should already have the
path discovery and path validation logic in place anyway so it's simply a
matter of linking the two with a bit of glue logic.  Further, 2560 servers
that rely on the acquisition of CRLs to supply BasicOCSPResponse would (I
presume) reject CRLs that fail to validate against a full path check.  They
too would (or should) have in place the raw materials necessary to path
discovery and path validation.

So implementing DPV is nothing more than a week's worth of glue logic and
some test cases.  And it's the testing, not code development, that'll
consume the bulk of that resource.

> I believe it will actually

We'd be happy to hear from you on a technical basis how the mechanisms we
propose fail to address this concern.  We could have overlooked something.

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 13 Nov 2000 13:39:28 -0800

Hi Mike,
    Are you saying that DPV/DPD would work with RFC 2560? If so,
how would you expect to address the issue of the client having
the hash of the CA's public key to create the correct OCSP request,
when it wants the OCSP/DPV/DPD responder to build up the path to
a trusted CA?

I thought I had raised this point a few times before, and that was
at least part of the reason why you chose to put out OCSPv2 and
DPV and DPD at the same time.

Regards,
Ambarish

P.S. About the rest of the points that you raise, I suppose we will
continue to disagree.

> From: Michael Myers [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 1:23 PM
> To: 'Ambarish Malpani'
> Cc: [email-masked] '
> Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
> 
> 
> Ambarish:
> 
> > Architect                                                
> 650.567.5457

---

From: Michael Myers <[email-masked]>
Date: Tue, 14 Nov 2000 01:04:30 -0800

Ambarish,

FYI, DPV and DPD can work with RFC2560.  They link into RFC2560's existing
extension mechanisms.  They also work with OCSPv2, so there's leverage
either way.  RFC2560's ASN.1 requirement in certID for a hash of the CA's
public key can be met by a null value for the hash of the CA's public key;
RFC2560 imposes no ASN.1 constraints on this value.  A standards-based
rationale for this practice would be useful.  We believe it better though to
expand the definition of certID, hence OCSPv2.  We hope you agree.  BTW, the
certID issue in no way stimulated production of the DPV and DPD proposals.

With respect,

Mike