Subject: RE: DPV vs SCVP

From: Michael Myers <[email-masked]>
Date: Wed, 15 Nov 2000 10:08:32 -0800

Denis,

Thanks for your in-depth review and comments on OCSPv2, both here and in
your off-list communications.  To my reading, you have four points:

Replace "good" with "not revoked"
---------------------------------
The last call for comments on the I-D that led to RFC2560 occurred roughly
two years ago.

Replace "unknown" with "revocation status unknown" 
--------------------------------------------------
See above.

It should not be manadatory to implement revocation status.
-----------------------------------------------------------
RFC2560 asserts that servers SHALL implement revocation status.  In other
words, "shall be capable of" in order to ensure a minimum level of
interoperability across the Internet.  It does not however require
deployment or activation of this functionality.  Does this clarification
satisfy your concern?

An alternative ASN.1 syntax that preserves compatibility.
------------------------------------------------------------
This one is worth some discussion on the list since it's at the core of what
OCSPv2 is all about.  The syntax that the OCSPv2 I-D proposes equally
intends to address backwards interoperability concerns.  It was informed by
the approach CMS took in addressing the same issue.  May I assume Denis that
you have no issue with the I-D's version number treatment?

Maybe the ASN.1 wizards out there could lend a hand here.  For ease of
analysis, we have:

    OCSPv2 -00 draft:
    -----------------
    Request   ::=     SEQUENCE {
       reqCert                     ReqCert,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

    ReqCert  ::=      CHOICE {
         certID            CertID,
         issuerSerial      [0] IssuerandSerialNumber,
         pKCert            [1] Certificate,
         name              [2] GeneralName }
  
    CertID   ::=      SEQUENCE {
         hashAlgorithm       AlgorithmIdentifier,
         issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
         issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
         serialNumber        CertificateSerialNumber }

    Version  ::=      INTEGER  {  v1(0), v2(1) }

    "If certID is used in ReqCert, the version number used SHALL be v1. If
any    
     other identifier is used, the version number used SHALL be v2."

    Denis proposes:
    ---------------
    Request  ::=     SEQUENCE {
         reqCert                     CertID,
         singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

    CertID   ::=     SEQUENCE {
         hashAlgorithm       AlgorithmIdentifier,
         issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
         issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
         serialNumber        CertificateSerialNumber,
         certHash            OCTET STRING     OPTIONAL,
         pKCert              Certificate      OPTIONAL }

    while, for completeness, RFC2560 states:
    -----------------------------------------
    Request   ::=    SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

    CertID    ::=    SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

The certHash option could be useful.  We chose not to include it to minimize
complexity.  We included a GeneralName option for environments that are best
enabled to PKI via Web-based naming schemes.  Given those observations, it
seems that we have either six or half a dozen.  It's still not clear to me
how your alternative formulation improves backwards interoperability beyond
that already proposed.  Or am I overlooking something?  Because I'm
otherwise strongly inclined to leave things as they are.  

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 13:37:29 +0100

Michael,

My original text contains several arguments; many of them do have no direct
answer in your reply. Please, next time, use my original text to reply.
Nevertheless, see my responses embedded in you new text.

> Replace "good" with "not revoked"

This is not an argument. The mis-use of "good", you currently make, is now
there to prove that there is a problem. Once again here is the text I
posted, on which you have not responded:

Extensions allows to request new services. The request for each every new
service may fail or succeed. This means that each extension will have to
carry the result of the request for the new service. This also means that
the current status will only carry the response to a *status revocation
request*, but will not carry any additional meaning. "Good" is not the
appropriate term to be used: "not revoked" is the right term and should be
used instead, when we revised OCSP.

> Replace "unknown" with "revocation status unknown"

The same.

> It should not be manadatory to implement revocation status.

This is not what I said. Here is my original text: 

" The real advantage to add DPV and DPD to OCSP is to be able to support
both
a revocation status request and DPV or DPV+DPD in a single request. It
should however be noticed that a response to a status revocation request is
not mandatory since the server may well return a "revocation status unknown"
response, but still respond to a DPD (Delegated Path Discovery) for the
certificate." 

Besides the exact wording, I would guess that we agree in principle on that
point.

> enabled to PKI via Web-based naming schemes.  

This is fairly insecure, hence why I have not kept that option.

> Given those observations, it

The explanations are the following:

If someone has implemented an OCSP v1 client, it can simply turn it into an
OCSP v2 client by only changing the version number in the protocol. Of
course, there will be no added functionality, but the advantage is that it
can then talk to an OCSP v2 server.

Since you privately mentionned that OCSP v2 would replace OCSP v1 (the draft
v2 is not clear on that point), it is an easy move. 

With the current structure proposed in OCSP v2, this cannot be done, since
the structure of the request is fairly different.

So my proposal is constructed in the following way:

1) keep the current structure of the request,
2) add optional fields in CertID which carry the possibility to identify a
certificate through "other means", e.g.:

     certHash            OCTET STRING     OPTIONAL,
     pKCert              Certificate      OPTIONAL

Note: If Rich things that using pKCert infringes a patent, we should
investigate this issue (or get rid of it).

This is the principle of the approach. If someone thinks that an additional
mean to identify a certificate should be added, it could be added to this
list as another optional element. 

It maybe the right time to mention that I have never be pleased by using:

instead of the issuer DN. 

The argument given at this time was the following: since the server has some
private agreements with a CA he is working for, it knows their names and
then can compute the hash of that name. If the service that is requested is
only a path discovery, then the argument does not stand anymore, since the
server may have access to a large number of certificates which are
identified by their name, not their hash. Adding "issuer" to the list of
optional parameters would thus make sense. 

Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions. 

In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense. 

I hope these explanations help.

Denis

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 16 Nov 2000 08:46:26 -0800

>Replace "good" with "not revoked"

OCSPv2 is a new protocol, which means that bugs in the old protocol 
can be fixed. I'm not saying that I agree with Denis' requests, but 
it is inappropriate to give an out of hand rejection to them simply 
because they had been discussed before, at the same time as the othe 
flaws in OCSP were being considered.

If the author of a document is not willing to work within the IETF 
framework, maybe it is time for a different author or additional 
co-authors, such as the ones who helped craft OCSPv1.

--Paul Hoffman, Director
--Internet Mail Consortium