Subject: RE: Clarification request on RFC 2560

From: Ryan Hurst <[email-masked]>
Date: Thu, 13 Sep 2001 20:59:57 -0700

Andrew --

	Nice to meet you, you will find my answers in line.

-----Original Message-----
From: Andrew Sciberras [mailto:[email-masked]] 
Sent: Thursday, September 13, 2001 7:31 PM
To: 'Ryan Hurst'
Cc: Pkix (E-mail)
Subject: RE: Clarification request on RFC 2560

Ryan,

I am at a loss to understand how the scenario which you have described below
will work.

Firstly, Your OCSP responder has 3 different signing certificates. Although
issued by different CA's, each certificate will  contain the same key data.

<rmh>Yes, what is a certificate after all but a mechanism to bind an
identity to a private key, this facilitates multiple authorities attesting
to the identity (and in this case authority to respond on its behalf)</rmh>

When you receive a single request that asks for the status of 3 unrelated
certificates, which certificate will you sign the single response with?

<rmh>remember you do not sign with a certificate you sign with a private
key, so the responder would sign with its "delegated" key</rmh>

From what I can see, section 4.2.2.2 states:
"..... They MUST reject the response if the certificate required to validate
the signature on the
 response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.
"

The point that must be satisfied by the scenario described above is #3
which, amongst other things, states that the signing certificate must be
issued by the CA that issued the certificate in question.
Although all three of your signing certificates have the same keys,
shouldn't the OCSP client have to validate the response by looking at the
actual signing certificate and verifying that it was actually issued by the
CA in question?

<rmh>You are correct we are looking to prove #3 in this case, the response
would have contained the each of the responder certificates associated with
the signature in the certs[] attribute (eg all three delegated responder
certificates). The client would then look at each of the CertIDs in the
response and then make sure that it had it can verify #3 against the certs[]
structure (of coarse after confirming that they are trusted).</rmh>

How should the OCSP Client proceed at this point, since there are 3
unrelated certificates in question, with only one certificate signing the
response?

<rmh>Let me know if this answers your question</rmh>

Andrew Sciberras
Software Engineer
Adacel Technologies Ltd

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ryan Hurst
> Sent: Friday, September 14, 2001 3:31 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers; Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
>
>
>
> Denis --
>
> 	I agree this is not terribly clear in the RFC and your
> question is a
> common one (maybe we can get some amended text in this regard
> in the RFC?).
> In MOST of the implementations I have looked at (ours
> included) the certs
> portion of the structure is used to provide the client with
> the certificates
> associated with the signature on the response.
>
> Consider this scenario; I have a single OCSP responder
> configured to serve
> responses for 3 un-related certificate authorities. The
> responder has CA
> delegated certificates (each CA has certified the same
> request and key pair)
> from each of these certificate authorities (as per section
> 2.2 and 4.2.2.2
> of the OCSP RFC [2560]). I have a client who sends a single
> OCSP request for
> statuses for 3 unrelated certificates (one from each of the previously
> mentioned CAs) to the responder. For the responder to produce
> a response
> this response that could be verified by the client it needs to provide
> certificates that could be chained back to the issuer of the
> certificates in
> question, since a ResponderID only provides the options to
> identify the
> responder byName or byKey the responder needs to provide the
> client with the
> certificates associated with the response. In this case 3 different
> certificates (once again all with the same key material) thus
> allowing the
> client to establish that response was signed by an authority
> delegated by
> each issuing CA.
>
> Using the certs[0] for a single responder chain would then
> limit a responder
> to serving responses for one CA in a delegated scenario as
> described above.
>
> Also the CA delegated scenario described by section 2.6 of
> the RFC [2560]
> states:
>
> "A certificate's issuer explicitly delegates OCSP signing authority by
> issuing a certificate containing a unique value for
> extendedKeyUsage in the
> OCSP signer's certificate. This certificate MUST be issued
> directly to the
> responder by the cognizant CA"
>
> I interpret this to mean that only the issuer of the certificate must
> explicitly delegate to this authority, as such when verifying
> a response in
> this case I would only need the signing certificate not its chain.
>
>
> Ryan M. Hurst
> ValiCert, Inc.
>
>
>  -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 13, 2001 3:20 AM
> To: pkix
> Cc: Mike Myers
> Subject: Clarification request on RFC 2560
>
>
>
> In RFC 2560 section 4.2.1 (OCSP Response), we have
>
> BasicOCSPResponse       ::= SEQUENCE {
>       tbsResponseData      ResponseData,
>       signatureAlgorithm   AlgorithmIdentifier,
>       signature            BIT STRING,
>       certs                [0] EXPLICIT SEQUENCE OF
> Certificate OPTIONAL }
>
> Usually every ASN1 field is explained, but in that document
> the certs field
> is not explained.
>
> Should that optional field be interpreted to carry a sequence
> of possibly
> useful certificates ?
>
> Denis
>

---

From: Dr S N Henson <[email-masked]>
Date: Fri, 14 Sep 2001 12:00:33 +0100

> structure (of coarse after confirming that they are trusted).</rmh>

I wonder how many OCSP clients actually behave like that? OpenSSL,
currently at least, doesn't.

An OCSP client might assume that only a single certificate corresponds
to the responder ID and for example just look for the first certificate
in the certs attribute which matches the reponder ID and verify that.
This would reject the response in the above scenario.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [email-masked] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

---

From: Rich Salz <[email-masked]>
Date: Fri, 14 Sep 2001 10:52:32 -0400

> in the certs attribute which matches the reponder ID and verify that.

I think most -- like 99.9999% -- PKI programs are not equipped to handle
cross-certified entities.
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 14 Sep 2001 11:48:50 -0400

Is that 99.9999% of all PKI programs (i.e. SSL clients, which are forbidden
from handling cross-certification*), or 99.9999% of those PKI programs,
such as S/MIME, whose specifications are not so short sighted as to forbid it?

Dave

* SSL 3.0: "certificate_list - This is a sequence (chain) of X.509 certificates,
            ordered with the sender's certificate first and the [sender's] root
            certificate authority last."

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 14 Sep 2001 18:51:54 +0200

>             certificate authority last."

So my question again: Is certs in the OCSP response:

 1) a sequence (chain) of X.509 certificates, ordered with the sender's
    certificate first followed by useful certificates ?

 2) a sequence (chain) of X.509 certificates, ordered with the sender's
   certificate and only one chain of certificates with the [sender's] 
   root certificate authority last ?

 3) a sequence (chain) of (always) "useful" X.509 certificates ?

 4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

In Section 4.1.2 which is specific to the request, the text says: "the
requestor MAY include certificates that help the OCSP responder verify the
requestor's signature in the certs field of Signature". The question is
whether "the requestor MAY include certificates that help the OCSP
responder" or whether "the requestor MAY include certificates that *MAY*
help the OCSP responder". In the fisrt case, they really help, so at least
some certificates from a valid chain shall be included. In the second case,
they MAY help, so they may also not help, so any kind of certificate may be
included.   
 
Note that the last interpretation allows for all the others.

Where do we go from this ?

Denis

---

From: John Thielens <[email-masked]>
Date: Fri, 14 Sep 2001 14:06:33 -0400

>  4) a sequence (chain) of (possibly) "useful" X.509 certificates ?

I believe #4 is the correct answer (I have seen enough variation in the ordering to preclude #1 and #2 -- perhaps this is why CMS uses SET OF instead of SEQUENCE OF, although it also commits the sin of OPTIONAL without SIZE (1..MAX)).  #4 puts the onus squarely on the relying party's shoulders to assess the applicability of the certificates to substantiate the signature.  Of course, the server SHOULD only put in useful certs, but the client MUST NOT count on it.

John

---

From: Rich Salz <[email-masked]>
Date: Fri, 14 Sep 2001 15:17:53 -0400

> such as S/MIME, whose specifications are not so short sighted as to forbid it?

With a claim like 99.9999% you want me to be specific?

I'm having trouble parsing that last line of yours.  Doesn't TLS allow
the client to send a "known CA" list?
	/r$

---

From: Eric Rescorla <[email-masked]>
Date: 14 Sep 2001 15:09:14 -0700

> the client to send a "known CA" list?
No--though there is some discussion of adding an extension for that purpose.

-Ekr

---

From: Rich Salz <[email-masked]>
Date: Fri, 14 Sep 2001 18:41:57 -0400

Off-list discussion, Eric clarified my incorrect memory allocation.  TLS
does allow the *server* to send a list of known CA's, not the client.

But I still don't understand this part of David's note:

> > > those PKI programs,
	/r$
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

---

From: Margus Freudenthal <[email-masked]>
Date: Mon, 17 Sep 2001 10:16:45 +0200

> I believe #4 is the correct answer (I have seen enough variation in the ordering to preclude #1 and #2 -- perhaps this is why CMS uses SET OF instead of SEQUENCE OF, although it also commits the si…
If the client can not count on something, this feature is not very
useful. In this case, the client must still implement functionality for
retrieving certificates needed for verification of the OCSP response
(this is a MUST, because I can't rely on the OCSP response itself).
Retrieving certificates from the OCSP response itself means that the
client developer must do additional work in hope that some OCSP
responder will put something useful in the response.

I would suggest explicitly stating the assumptions that the client can
make about the content of the certs field, and if these assumptions
consist of an empty set, removing this field as it only complicates
things without providing any measurable value.

-- 
Margus

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Sep 2001 11:07:39 +0200

Margus,

> > I believe #4 is the correct answer (I have seen enough variation 
> > in the ordering to preclude #1 and #2 -- perhaps this is why CMS 
> > uses SET OF instead of SEQUENCE OF, although it also commits the 
> > sin of OPTIONAL without SIZE (1..MAX)).  #4 puts the onus squarely 
> > on the relying party's shoulders to assess the applicability of 
> > the certificates to substantiate the signature.  Of course, the
> > server SHOULD only put in useful certs, but the client MUST NOT 
> > count on it.

> useful. 

In the ASN1 syntax that field is OPTIONAL. So the client cannot assume 
that he will always be present, ... unless we write a profile of that 
document where we make that field mandatory.

Denis

> In this case, the client must still implement functionality for

---

From: John Thielens <[email-masked]>
Date: Mon, 17 Sep 2001 10:29:28 -0400

> things without providing any measurable value.

Part of this depends on the trust model between the client and the server.  If there were no certs in the request, this would require the server to have foreknowledge of the requester's certificate, indexed by its name (requestorName).  By allowing the requester to supply certs, presumably a cert chain up to but not including some trust root expected at the server, this makes the protocol more flexible.

Ditto for the certs in the response from the server.  This is very common practice and appears in protocols like SSL/TLS, CMS (S/MIME), and so on.

The reason I say the entity using the certs MUST NOT count on any particular meaning to the order or presence of the certs is because normal path discovery and path validation rules apply here per 2459 (sec. 6.1 -- although this is somewhat thin on discovery).  Before path validation, the client counts on nothing.  But after path validation, the client knows exactly what to trust.

John