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

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 14 Nov 2006 11:07:51 -0800

In hurry, I did not clearly articulate my thoughts.  What I am saying also
relates to another comment to Mike Myers regarding the security of the
delegated model which is incompletely addressed by 2560.

I will be verbose this time.

The implementations such as Corestreet and Tumbleweed tend to adhere to the
approach that the same key that signed the certificate in question, sign the
OCSP Responder certificate.

Thus, if you have a hierarchy like Root --> CA --> Subscriber and you want
the status of CA certificate and the Subscriber certificate, you get them as
responses and with them you only need the two OCSP Responder certificates
one signed by the Root (for verifying CA certificate revocation status) and
one signed by the CA (for verifying the subscriber certificate revocation
status).

You do not need any paths.

Please note that the approach also works when the Responder is queried by a
CA cross certified by the root, since rest of the path has been built by the
client. 

-----Original Message-----
From: Dave Engberg [mailto:[email-masked]] 
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: Russ Housley <[email-masked]>
Date: Tue, 14 Nov 2006 18:42:07 -0500

Santosh:

I believe this is a red herring.  This is not the only deployment 
approach supported by RFC 2560.

Russ