IETF Logo Mail Archive

Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Sam Hartman <hartmans-ietf@mit.edu> Fri, 17 November 2006 17:59 UTC

Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl7zp-0004TQ-O3 for pkix-archive@lists.ietf.org; Fri, 17 Nov 2006 12:59:25 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gl60m-0006uQ-2M for pkix-archive@lists.ietf.org; Fri, 17 Nov 2006 10:52:25 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHEXgWa060322; Fri, 17 Nov 2006 07:33:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kAHEXgPO060321; Fri, 17 Nov 2006 07:33:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kAHEXdS0060306 for <ietf-pkix@imc.org>; Fri, 17 Nov 2006 07:33:41 -0700 (MST) (envelope-from hartmans@mit.edu)
Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4B3D9E0038; Fri, 17 Nov 2006 09:33:22 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Stefan Santesson <stefans@microsoft.com>
Cc: Ryan Hurst <Ryan.Hurst@microsoft.com>, "Price, Bill" <wprice@mitre.org>, Michael Myers <mmyers@fastq.com>, Russ Housley <housley@vigilsec.com>, Paul Hoffman <paul.hoffman@vpnc.org>, "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: Re: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
References: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800344D6B8@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <F9F038204EE77C4AA9959A6B3C94AFE8010EF549@IMCSRV2.MITRE.ORG> <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800344D7FF@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <A15AC0FBACD3464E95961F7C0BCD1FF015681C06@EA-EXMSG-C307.europe.corp.microsoft.com>
Date: Fri, 17 Nov 2006 09:33:22 -0500
In-Reply-To: <A15AC0FBACD3464E95961F7C0BCD1FF015681C06@EA-EXMSG-C307.europe.corp.microsoft.com> (Stefan Santesson's message of "Fri, 17 Nov 2006 12:06:34 +0000")
Message-ID: <tslirheta6l.fsf@cz.mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2

>>>>> "Stefan" == Stefan Santesson <stefans@microsoft.com> writes:

    Stefan> Could we just define this error response as "Unsupported
    Stefan> request". This could describe the case where the server in
    Stefan> unable to respond to a syntactically well formed request,
    Stefan> either because it requires a non-supported response or the
    Stefan> server is unauthorized to respond.  It would provide two
    Stefan> important pieces of information

    Stefan> 1) The request was well formed, so there was no error in
    Stefan> the request; and 2) The responder can't respond to this
    Stefan> request, so there is no point in retrying the same request
    Stefan> to this responder.

    Stefan> I think this is enough information for client to
    Stefan> gracefully handle the situation and move on with other
    Stefan> available status validation options such as:

I'm not sure this is quite enough information.  I think that you need
to somehow indicate the mandatory to implement minimal response set so
clients can fall back to that when they get this error.

I.E. if I only know how to use OCSP and I get this error there should
be guidance telling me to retry without a nonce, with one cert and
without options.


Now, in the interests of moving forward, I'm willing to let this slide
especially since the lw profile gives you that guidance and especially
if we're eventually going to do a 2560bis.  2560bis would actually
need to speak to mandatory to implement behavior.

v2.23.0 | Report a Bug | By Email