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

From: Carl Wallace <[email-masked]>
Date: Tue, 14 Nov 2006 15:48:46 -0500

I've worked with a toolkit that can send multi-cert requests and have seen
problems in this area including responders that return a successful response
for one cert included in a request without addressing the others.  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Engberg
> Sent: Tuesday, November 14, 2006 12:45 PM
> To: Stefan Santesson; Santosh Chokhani; Russ Housley; Price, 
> Bill; [email-masked]
> Cc: Sam Hartman; Michael Myers
> Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> 
> 
> 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
> Windows Security, Standards
> 
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: den 14 november 2006 03:59
> > To: Stefan Santesson; Russ Housley; Price, Bill; [email-masked]
> > Cc: Sam Hartman; Michael Myers; Dave Engberg
> > Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
> >
> > 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:owner-ietf- 
> > [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: "Price, Bill" <[email-masked]>
Date: Tue, 14 Nov 2006 17:51:11 -0500

I have seen this behavior also (I mentioned it in my first post on this
thread). Keyed responders responded correctly. The problem of partial
responses occurred with at least one keyless responder. Such responses
appear to be out of compliance with RFC 2560 since it is not the case
that "A definitive response message is composed of responses for each
of the certificates in a request." 

If a responder that is multi-request challenged is supposed to give an
error, neither the standard nor the profile explicitly identify the
appropriate error message. If the choice of error message is limited to
the existing ones in the RFC, the error will likely be as informative
and helpful as the profile's "unauthorized" response is for the case
when the keyless responders don't have an appropriate presigned
response. 

If the partial response is to be acceptable, it seems that at least one
of the RFC or profile should be modified to so state. 

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

I've worked with a toolkit that can send multi-cert requests and have
seen
problems in this area including responders that return a successful
response
for one cert included in a request without addressing the others.