Subject: RE: OCSP I-Ds going forward

From: "Tom Gindin" <[email-masked]>
Date: Mon, 2 Dec 2002 17:34:21 -0500

You are quite right that if you don't preserve having CertID remain
as the meaning of the Universal SEQUENCE tag in that context, you'll break
backward compatibility, and that the obvious way to avoid that is to make
CertID an untagged member of a CHOICE.
      Should we really rush into making this a SEQUENCE when the various
elements of the choice are so near being redundant with each other?
FullCertificate includes all the data within issuerSerial, as does
certIDWithSignature.  So neither of these makes any sense with issuerSerial
in the same SEQUENCE, and I really don't see why
      The following structures have been proposed in this discussion: a -
CertID, b - fullCertificate, c - issuerSerial, d - certIDWithSignature, e -
ESSCertID, f - IssuerBasedID.  If b is present, c, d and e are pointless
and only one of a or f makes any sense since the only extra value added by
either of them is the optimization of permitting a hash of the issuer's
certificate or key to replace the validation of the certificate's
signature.  If either f or d is present, c is pointless, and since c is an
optional component of e there's no point in specifying separate syntax for
it, so c is useful only by itself or as a supplement to a.  I doubt if
there's any real point to having e if you're using f and there's no point
in having a if you have f.  So the uses containing c are c and c+a, the
uses containing f are f, f+d, and f+b, the other uses containing b are b
and b+a, and while there are conceivable arguments for the full set of
combinations of a, d, and e I would argue that e+a with issuer name present
in e is clearly superior to any combination involving d with either e or a
- or for that matter to d at all.  So we have a bunch of fields by
themselves, a with b, c, or e, and f with b or d.  We can probably kill off
f as well, since e and a are not new and e+a does everything that f does.
This reduces the matrix to four single fields (CertID, fullCertificate,
issuerSerial, and ESSCertID), and CertID with any one of the other three.
      The ASN.1 corresponding to this analysis is
      NewOCSPIDVariants ::=         CHOICE {
            full  [0]   FullCertificate,
            mime  [1]   IssuerSerial,
            ess   [2]   ESSCertID -- with IssuerSerial present
      }
      CHOICE      {
            CertID,
            COMPONENTS OF NewOCSPIDVariants,
            combo [3] IMPLICIT SEQUENCE {
                  CertID,
                  NewOCSPIDVariants
            }
      }

            Tom Gindin

"Michael Myers" <[email-masked]> on 11/27/2002 02:37:11 PM

To:    "Phillip H. Griffin" <[email-masked]>
cc:    "Peter Gutmann" <[email-masked]>,
       <[email-masked]>, Tom Gindin/Watson/IBM@IBMUS,
       <[email-masked]>
Subject:    RE: OCSP I-Ds going forward

Phil,

Thanks for the attention.  I will put this into what is quickly
becoming core-01.  By the way, is my ASN.1 reasoning correct?

Mike

> -----Original Message-----
> From: Phillip H. Griffin [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 11:31 AM
> To: Michael Myers
> Cc: Peter Gutmann; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: OCSP I-Ds going forward
>
>
> Michael,
>
> Please include the certHash choice alternative or
> optional component of
> this type in the OCSP solution. Others depend on this
> alternative in the
> definition as an easy means of identifying a
> certificate. And please use
> OCTET STRING instead of BIT STRING or REAL or some other
> type for this value.
>
> This from http://www.normos.org/ietf/rfc/rfc2634.txt in 1999
>
>    ESSCertID ::=  SEQUENCE {
>         certHash                 Hash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
>
>    Hash ::= OCTET STRING -- SHA1 hash of entire certificate
>
>
> And this from
> http://www.normos.org/ietf/rfc/rfc3126.txt September 2001
>
>    OtherCertID ::= SEQUENCE {
>         otherCertHash            OtherHash,
>         issuerSerial             IssuerSerial OPTIONAL
>    }
>
>    OtherHash ::= CHOICE {
>        sha1Hash OtherHashValue,  -- This contains a SHA-1 hash
>        otherHash OtherHashAlgAndValue
>    }
>
>    OtherHashValue ::= OCTET STRING
>
>    OtherHashAlgAndValue ::= SEQUENCE {
>      hashAlgorithm  AlgorithmIdentifier,
>      hashValue      OtherHashValue
>    }
>
> The later is what is now used in X9.73 CMS, soon to be
> published. It is the only choice alternative supported in
> OASIS XCBF and X9.84.
>
> Phil
>
>
>
>
>
> Michael Myers wrote:
>
> >Peter,
> >
> >I agree with your views re: issuerAndSerialNumber.
> In general,
> >since this is an IETF WG after all, we should be
> first focused
> >on supporting other IETF work that relies on PKI and PKIX.
> >Conversely, I think it only fair that the consituency Denis'
> >formulation addresses deserves WG consideration as
> well.  That's
> >why, in the draft-ietf-pkix-ocsp-core-00.txt
> document I recently
> >sent to Internet Drafts there's
> >
> >ReqCert ::= CHOICE {
> >   certID                    CertID,
> >   issuerSerial              [0] IssuerAndSerialNumber,
> >   fullCert                  [1] FullCertificate,
> >   certIdWithSignature       [2] CertIdWithSignature }
> >
> >Perhaps, as you say, it should be SEQUENCE.  The only issue I
> >have with that is that to my recollection and
> understanding of
> >ASN.1 details the above CHOICE allows backwards
> interoperability
> >with v1 envirionments via use of the CertID choice because
> >there's no change in ASN.1 type tags in that
> instance.  I'm no
> >ASN.1 expert.  I mostly fake it from worked
> examples.  But might
> >the following achieve both objectives?
> >
> >ReqCert ::= CHOICE {
> >   certID                    CertID,
> >   other                     [0] SEQUENCE . . . }
> >
> >Meanwhile I'm putting the finishing touches on the
> Servives and
> >Extensions document (i.e.
> draft-ietf-pkix-ocsp-services-00.txt).
> >That delay is mostly a systems engineering matter of parsing
> >through the DPV/DPD requirements in RFC3379 to ensure
> >compliance.
> >
> >With any luck at all, this work will bring a degree
> of coherence
> >and closure to our invention of this wheel.
> >
> >Mike
> >
> >
> >
> >
>
>

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 2 Dec 2002 15:01:49 -0800

Tom,

Am I correct in inferring that your are advocating:

> This reduces the matrix to four single fields 
> (CertID, fullCertificate, issuerSerial, and ESSCertID)

Mike