Subject: Re: I-D ACTION:draft-ietf-pkix-ocspv2-ext-00.txt

From: [email-masked] (Peter Gutmann)
Date: Sat, 23 Nov 2002 22:13:10 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:

>- in addition to the current way to define a certificate, two new ways have
>   been defined.
>
>This is fully aligned with the discussion on the list.

Not at all, the CertIdWithSignature is a weird mutation of what was discussed,
because it piles a jumble of bits and pieces into a sequence rather than using
the straightforward IDs like issuerAndSerialNumber.  The rationale for the
different identifiers (e.g. issuerAndSerialNumber, certificate
fingerprint/thumbprint/whatever-you-want-to-call it) is fairly clear, but the
stuff in CertIdWithSignature is just plain strange, and entirely redundant.  I
can probably fix this by using only issuerAndSerialNumber and stuffing dummy
data in the other fields on the assumption that no-one else will be able to
make heads or tails of them either (experience with other PKI procotols has
shown that this works almost all of the time), but why is this stuff needed at
all?  What's wrong with using what was in the original OCSPv2 draft, a simple
cut-and-paste of obvious, sensible cert identifiers?

Peter.

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 23 Nov 2002 10:35:38 -0800

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Peter Gutmann
>
> What's wrong with using what was in the
> original OCSPv2 draft, a simple cut-and-paste of
> obvious, sensible cert identifiers?

I think this makes sense.  It is a point on which this I-D's
coauthors couldn't entirely agree so I left it as expressed in
the -00 iteration anticipating this reaction.  My reasoning for
getting this I-D out was to separate v2-ness issues away from
the DPV/DPD issues.

What makes the most sense going forward is to have two separate
working documents: 1) a "core framework" syntax; and 2) a
"services and extensions" document; especially since this most
recent I-D also proposes a new CRL Locator extension.

This approach has the benefit of fitting well against the
upcoming DPV/DPD decision-making process while accommodating
parallel list dialog on cert id mechanisms.  All previous and
proposed services/extensions will be lumped together, including
the originally proposed DPV and DPD extensions.  The DPV/DPD
poll then determines whether or not to retain that portion of
text in the services and extensions I-D.

Mike

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 25 Nov 2002 09:42:51 +0100

Michael,

> recent I-D also proposes a new CRL Locator extension.

I strongly disagree.

I believed that the "battle" with OCSPv2 was over since, we (Ambarish, you 
and me) agreed to restrict its use to the checking of the revocation status 
of a certificate, but in no way to validate a certificate against a policy.

Now, I can see that you do not agree any more with that position.

> text in the services and extensions I-D.

I fully disagree with that approach that would take us two years back.

Denis

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 25 Nov 2002 12:10:09 -0800

> I believed that the "battle" with OCSPv2 was over
> since, we (Ambarish, you and me) agreed to restrict
> its use to the checking of the revocation status

Denis,

I have never agreed to this structural limitation in OCSP scope.
Rather, I took and continue to accomodate a phased approach. Had
you been in Atlanta you would have heard me repeat myself for
the umpteenth time on this.  My response to you is essentially
the "OCSP for DPV/DPD" pitch I gave in Atlanta, so here it is in
amended form for those WG members unable to attend.

I'm doing so with a view towards the upcoming DPV/DPD vote as
Peter Sylvester did so recently for DVCS.  I respectfully
suggest you do likewise regarding CVP rather than to continue to
argue this point.  The outcome of Atlanta was clear.  We have
argued enough.  It is time to put this issue to the list.

[BEGIN PITCH]

What we now refer to as DPV was the original intent of the I-D
that ultimately became RFC 2560. That, and doing something about
CRL latency and the diversity of CRL retrieval mechanisms.
However, in the formative phases of RFC 2560, the needs of the
financial community were successfully persuasive in deferring
action on path validation due to its rathole potential in favor
of at least addressing the more easily resolvable revocation
issues.  A middle ground was achieved via the use of service and
extension hooks, these being:

1. requestExtensions in TBSRequest syntax;

2. singleRequestExtensions in Request syntax;

3. responseType in Response syntax;

4. the name id-pkix-ocsp-basic as a response type;

5. the AcceptableResponses extension which includes
   in its definition the text: "An OCSP client MAY
   wish to specify the kinds of response types it
   understands."; and

6. responseExtensions in Response syntax.

One can also see evidence of the original intent throughout
2560's text.  For example:

"There is one basic type of OCSP response that MUST be
supported by all OCSP servers and clients. The rest of
this section pertains only to this basic response type."

PKIX succeeded with RFC 2560 in establishing a framework for
online certificate status services.  There now exists a critical
mass of deployed and supported OCSP servers and OCSP-enabled
clients.  It's time we go back and finish the job of engineering
a DNS for PKI.

[END PITCH]

Mike