Subject: RE: OCSP I-Ds going forward

From: "Michael Myers" <[email-masked]>
Date: Mon, 25 Nov 2002 15:31:14 -0800

> From: Tom Gindin [mailto:[email-masked]]
> 
> If the purpose of CertIdWithSignature is to 
> extend IssuerSerial in a way which is both
> unambiguous and compact, why are both the
> signatureValue field and tbsCertificateHash
> present?
> 

Tom,

What would you prefer?

Mike

---

From: "Tom Gindin" <[email-masked]>
Date: Wed, 27 Nov 2002 15:10:25 -0500

Phil, Peter:

      Since OCSP might be considered to have a special responsibility
because it's hiding the CRL's from the consumer, and thus hiding the fact
that the certificate and the CRL come from different actual authorities, it
probably should allow a client to use more than just IssuerSerial.  If an
S/MIME application picks up the wrong certificate because of two issuer's
using the same DN, it gets a false negative ("this wasn't signed by that
cert at all"), while OCSP could produce a false positive ("this cert is
still valid").
      Denis' suggested processing model for OCSP responders would work
better with the issuer key or certificate as the base of the hash rather
than the subject certificate.  My own temporary draft for this purpose,
which reduces to IssuerSerial if you don't use the extra fields, was:
      IssuerBasedID     SEQUENCE ::= {
            COMPONENTS OF IssuerSerial,
            issuerCertHash    OCTET STRING OPTIONAL,
            hashAlg     AlgorithmIdentifier DEFAULT { id-sha1, NULL }
      }

      The difference between this and ESSCertID with IssuerSerial present
is small enough that in the interests of standardization taking ESSCertID
from RFC 2634 might be better.

            Tom Gindin

"Phillip H. Griffin" <[email-masked]>@mail.imc.org on 11/27/2002
02:31:06 PM

Sent by:    [email-masked]

To:    Michael Myers <[email-masked]>
cc:    Peter Gutmann <[email-masked]>, [email-masked],
       Tom Gindin/Watson/IBM@IBMUS, [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: [email-masked] (Peter Gutmann)
Date: Thu, 28 Nov 2002 19:35:21 +1300 (NZDT)

[CC'd to the list since it's of general relevance]

Stephen Kent <[email-masked]> writes:

>My suggestion is that you try to get the OCSPv2 authors to adopt your
>suggestions, as a way of getting this into the standards track document.

As my "Eddie the Shipboard Computer" comment pointed out, I'm not optimistic
about this happening :-(.  The consensus of the debate on the newsgroup a
month or two back was that we needed a simple, straightforward cert identifier
to resolve the interop problems caused by the complex v1 identifier.  The
authors' response was to invent a new identifier just as complex as the v1
one, only different.  In other words instead of simplifying things as the WG
asked for, they did the opposite and made things worse rather than better - we
now have two unworkable identifiers instead of one to deal with.

All we need is a single, simple, universal ID which will be present in
requests which uniquely IDs all certs.  The smorgasbord in my pseudo-draft
isn't strictly necessary (it was mostly for compatiblity with existing
standards), just a certID will do.  I don't really want to get involved in
ideological debates on identifying certs or PKI design, I just want to be able
to ship code where I can guarantee that it'll talk to everything else without
weeks of hair-pulling and finger-pointing between vendors of incompatible
products.

A workable compromise, I think, is to have:

v2CertID ::= SEQUENCE {
  certHash   OCTET STRING,
  <whatever> ANY OPTIONAL
  }

where <whatever> can include as many DNs and hashes and bits of keys and
serial numbers and FFTs of the cert and MPEGs of cats and whatever as required
to make people happy.  I've picked the certHash as the one MUST because it's
the only guaranteed-unique single value for a cert (vs. issuerAndSerialNumber,
keyIdentifier, etc etc, which everyone is going to nitpick endlessly) so it
should be beyond reproach.  It also works nicely with the case of dropping the
value into a pre-built query that I mentioned earlier, and is the most compact
ID form for bandwidth-limited environments.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 28 Nov 2002 19:51:06 +1300 (NZDT)

"Phillip H. Griffin" <[email-masked]> writes:

>[...]
>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.

That's a nice form, since it simplifies to an OCTET STRING SIZE(20) for the
most common (let's face it, probably the only) case.  That'd get my grunt of
approval.

>And please use OCTET STRING instead of BIT STRING or REAL or some other type
>for this value.

Naah, UniversalString in an EMBEDDED PDV!  They don't get nearly enough use,
for some reason.

Peter.