[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
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.
---------------------------------------------------------------------
Ambarish Malpani
Architect 650.567.5457
ValiCert, Inc. ambarish@valicert.com
339 N. Bernardo Ave. http://www.valicert.com
Mountain View, CA 94043
> -----Original Message-----
> From: Michael Myers [mailto:MMyers@verisign.com]
> Sent: Monday, November 13, 2000 1:23 PM
> To: 'Ambarish Malpani'
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: Which protocol - SCVP or OCSPv2 with OCSPpath/OCSPvalid?
>
>
> 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
> >
> >
> >
>