RE: OCSP I-Ds going forward

["Michael Myers" <myers@xxxxxxxxxxxxx>]

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