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

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

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 10:31:37 -0500

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