Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Nov 2006 03:58:41 -0800

Stefan,

You are making more complex than it is.  The Responder can include all
the CA certificates that issued the certificate in question and AIA can
do the rest.

Furthermore, since most PKI are two tier hierarchy, in Enterprise
environment, the CA certificate certification path is not an issue.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Monday, November 13, 2006 6:54 PM
To: Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

I'm not sure the case described is a realistic one.

Section 2.2
   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

Since the request is on certificates issued by 2 different CA:s trust
option 1 is invalid.
Trust option 3 is valid in theory but in practice it requires that the
OCSP responder provide multiple validation paths in the response, one
for each issuing CA. Somehow I doubt that this is implemented by anyone.

Trust option 2 is not generic and is only valid as a result of a local
configuration.

So I don't think this is a problem only for key-less responders.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Russ Housley
> Sent: den 13 november 2006 14:08
> To: Price, Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers; Dave Engberg
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>
> I prefer an error that tells the client to ask for the certificate
> one at a time.
>
> Russ
>
>
> At 02:46 PM 11/13/2006, Price, Bill wrote:
>
> >I'd suggest focusing on understanding where responses to the keyed
and
> >keyless responders inherently differ. I am aware of two general
cases:
> >
> >1) The request asks for the status of multiple certificates that have
> >not been included in a single presigned response. Russ's example fits
> >into this case. The keyed responder handles, but the keyless will
fail
> >for the general case. Some responders respond with the presigned
> >response that includes one of the certificates (usually the first) in
> >the request. A common situation is to ask for the status of
> >certificates in a chain. Santosh points out some keyless responders
> >anticipate this and bundle responses accordingly.
> >
> >2) The request is "well-formed" but asks for the status of a
> >certificate for which the keyless responder has not prepared a
> >response.  This situation will occur if:
> >
> >     a) The request is for status of a certificate from a supported
CA
> >but with a serial number for which there is no pre-signed response.
> >Assuming presigned responses exist for all certificates that would be
> >valid based on their validity intervals, this would occur if the
> >certificate had expired or was yet to be issued (I am aware the
> keyless
> >responders generally produce responses for certificates likely to be
> >issued before the next generation of presigned responses). The keyed
> >responder would give a signed "good" response. My understanding is
> that
> >the keyless responder under the draft lightweight OCSP responds with
> an
> >unsigned "unauthorized" error code.
> >
> >     b) The request is for the status of a certificate from an
> >unsupported (or non-existent) CA. The keyed responder would respond
> >with a signed "unknown" response while under the draft, the keyless
> >would again respond with the unsigned "unauthorized" error  code.
> >
> >Some might argue with some grounds that these differences are
unusual,
> >unlikely, and insignificant.
> >
> >I personally consider the behavior in 2 of responding with the
> >"unauthorized" error to be misleading. "Internal error" sounds more
> >appropriate if I were constrained to the current error codes.
> >"Malformed request" might be OK. However, the actual situation does
> not
> >match well with any of these errors as they are described in 2560.
> >
> >If 2560 is supposed to encompass keyless responders, I'd recommend
> >identifying the unavoidable differences and/or adding 2 TBD error
> codes
> >for the above cases (assuming they are the only differences). The
> first
> >error can be worked around by breaking the request for status of
> >multiples into multiple requests for status of one cert.
> >
> >We've also seen some problems with client apps that can't handle
> >presigned responses that commonly contain the status of several
(e.g.,
> >15-25) certs. The apps inquired for the status of a single cert and
> >apparently expected a response for a single certificate. I'd suggest
> >that some "must" or "should" words address clients' ability to handle
> >the situation of a response covering multiple certificates.
> >
> >
> >
> >Bill Price
> >
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Russ Housley
> >Sent: Monday, November 13, 2006 11:46 AM
> >To: Michael Myers; Dave Engberg
> >Cc: [email-masked]; Sam Hartman
> >Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> >
> >Mike:
> >
> >I think it is not that simple.  I think you need to say that support
> >for one certificate MUST be supported, and that support for more than
> >one certificate is OPTIONAL.  Then, the error is am indication that
> >the requestor has selected an unimplemented OPTION.
> >
> >Russ
> >
> >At 06:52 PM 11/12/2006, Michael Myers wrote:
> > >Responders unable to produce or acquire a definitive response MUST
> >return <a
> > >TBD error>.
> > >
> > >As to your other points Santosh, that is something I prefer the
> chairs
> > >consider.
> > >
> > > > -----Original Message-----
> > > > From: Santosh Chokhani [mailto:[email-masked]]
> > > > Sent: Sunday, November 12, 2006 3:36 PM
> > > >
> > > > Mike,
> > > >
> > > > What is the error case?
> > > >
> > > > . . .

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Nov 2006 17:11:07 +0000

Santosh,

I didn't say it was hard. I say that I doubt that there are many implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

> Sent: den 14 november 2006 03:59
> To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> [email-masked]]

---

From: "Dave Engberg" <[email-masked]>
Date: Tue, 14 Nov 2006 12:44:51 -0500

CoreStreet's OCSP server doesn't include a SingleResponse for the issuing
CA's cert in pre-signed responses.  Mostly for the reasons mentioned:

Adds 90-100 bytes onto every response

Have never seen a relying party app/plug-in send a request like this

The "delegated" trust model in RFC 2560 would require different signing
certs for trusting entity vs. CA cert ... add another 1kB onto the response

Protocol only sends CA name+key info, which isn't enough to identify which
CA cert the relying party is inspecting in the case of CA cert renewal,
cross-certification, etc.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 12:11 PM
To: Santosh Chokhani; Russ Housley; Price, Bill; [email-masked]
Cc: Sam Hartman; Michael Myers; Dave Engberg
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 15 Nov 2006 08:35:51 -0800

Although I know of toolkits that can send requests like this, and
servers that can respond like this I know of no clients that send
requests like this.

Ryan

-----Original Message-----
Sent: Tuesday, November 14, 2006 9:11 AM

Santosh,

I didn't say it was hard. I say that I doubt that there are many
implementations supporting this scenario even those with a responder
key.
It would be interesting to hear from implementers if I'm right.

Stefan Santesson
Senior Program Manager