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

[Michael Myers <MMyers@xxxxxxxxxxxx>]

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:ambarish@valicert.com]
> Sent: Friday, November 10, 2000 1:42 PM
> To: 'ietf-pkix@imc.org '
> Subject: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
> 
> 
> 
> 
> 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

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.

> - 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 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 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?

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

> - 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.

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

> - 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

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.

> - 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

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.

> 
> Issues with this approach
> -------------------------
> - It is very unclear to me that OCSPvalid is trying to do the
> 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
> 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.

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.

> 
> 
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  ambarish@valicert.com
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
>  
>