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

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 15 Nov 2006 11:22:01 -0800

Russ,

The OCSP field in the AIA extension helps the OCSP client locate an OCSP
Responder.  But, to verify the signature on the OCSP response, 2560
mandates three trust models: explicitly trusted, CA only, and CA
delegated.  The OCSP field can not extend those options to other trust
models.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 10:32 AM
To: Santosh Chokhani; [email-masked]
Cc: Sam Hartman
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Santosh:

My point is that the request could be for any set of certificates 
that contain AIAs that point to the same OCSP responder, whether they 
are part of the same certification path or not.

Russ

At 08:03 PM 11/14/2006, Santosh Chokhani wrote:
>Russ,
>
>I do not know how germane this debate is to Sam's question, but I was
>simply responding to the issue building certification path.  I presume
>that in this context it relates to building a path to the Responder
>certificate.
>
>Now let us look at the three model 2560 has: Explicitly Trusted, CA and
>Delegated.
>
>Explicitly trusted does not need a certification path and hence there
is
>no issue and that is why I did not include it in.
>
>CA model does not need any path building since path to the CA has
>already been built and that is why I did not include it in my response.
>Note that both clients requires the CA to use the same to sign the OCSP
>as it signed the certificate in question with.
>
>My post responded to the Delegated model.
>
>I hope this clarifies that the path building should not be a major
issue
>for all three models 2560 supports.
>
>-----Original Message-----
>From: Russ Housley [mailto:[email-masked]]
>Sent: Tuesday, November 14, 2006 6:42 PM
>To: Santosh Chokhani; [email-masked]
>Cc: Sam Hartman
>Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560
>
>Santosh:
>
>I believe this is a red herring.  This is not the only deployment
>approach supported by RFC 2560.
>
>Russ
>
> >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: Wed, 15 Nov 2006 15:27:41 -0500

I agree.  I can see where two of these models can be used in the 
multi-certificate request.  That is why I think that this dimension 
of the discussion is a red herring.

Russ