Subject: Re: DPV vs SCVP

From: "Rich Ankney" <[email-masked]>
Date: Wed, 15 Nov 2000 16:10:39 -0500

I prefer the first version of CertID, although I'm interested in hearing
more
from Denis about the difference in backward compatibility between the
two.  I'd also like to see the certHash alternative in the first version (to
handle alternative cert formats like X9.68 that have no explicit issuer
and serial # fields).  I COULD also do this using the "name" alternative
and defining an OTHER-NAME to carry the X9.68 "Owner" syntax.

This assumes the "name" alternative refers to the subject name of the
cert in question, but that begs the question of how to handle the case
where a  subject has multiple (X.509) certs (with the same subject name).

Regards,
Rich

-----Original Message-----
From: Michael Myers <[email-masked]>
To: Denis Pinkas <[email-masked]>; Michael Myers
<[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, November 15, 2000 1:14 PM
Subject: RE: DPV vs SCVP

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