Subject: RE: Clarification request on RFC 2560

From: Ambarish Malpani <[email-masked]>
Date: Thu, 13 Sep 2001 10:56:51 -0700

See section 4.1.2. It is explained over there.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----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: Ambarish Malpani <[email-masked]>
Date: Thu, 13 Sep 2001 17:40:42 -0700

Sorry, Denis/Ryan. My mistake. Have clarified the use of that
field in responses in the candidate for a Draft Standard.

Regards,
Ambarish

> From: Ryan Hurst 
> Sent: Thursday, September 13, 2001 5:15 PM
> To: Ambarish Malpani
> Subject: RE: Clarification request on RFC 2560
> 
> 
> Ambarish that text is specific to the request...
> 
> Ryan
> 
> From: Ambarish Malpani [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2001 10:57 AM
> To: 'Denis Pinkas'; pkix
> Cc: Mike Myers
> Subject: RE: Clarification request on RFC 2560
> 
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 14 Sep 2001 09:36:21 -0700

Rich --

	I would agree with that, however I do not see this case as being a
cross certification case; can you elaborate?

Ryan

-----Original Message-----
From: Rich Salz [mailto:[email-masked]] 
Sent: Friday, September 14, 2001 7:53 AM
To: Dr S N Henson
Cc: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560

> 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.

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: Ambarish Malpani <[email-masked]>
Date: Fri, 14 Sep 2001 09:38:33 -0700

Hi Steve,
    I would hope a lot of the clients would support this
capability (of a server supplying multiple certs in a response,
each showing that it had delegated authority from multiple CAs).

A lot of our customers run our server in a mode where it supports
multiple CAs - frequently multiple CAs that form a hierarchy.

By allowing a server to supply delegated certificates from multiple
CAs, a client can make a single query to a VA for a whole chain
(where the VA is the designated responder for all CAs in the chain).

This gives people a reasonable amount of efficiency - client needs
to make a single query for a whole chain.

If a client were not to support multiple delegated certs in a
response, it would need to make multiple queries.

Regards,
Ambarish

P.S. I know that we have supported this behavior in our toolkit
and apps for some time.

> From: Dr S N Henson [mailto:[email-masked]]
> Sent: Friday, September 14, 2001 4:01 AM
> To: Pkix (E-mail)
> Ryan Hurst wrote:
> > <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>
> > 
> 
> I wonder how many OCSP clients actually behave like that? OpenSSL,
> currently at least, doesn't.
> 
> 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: Ambarish Malpani <[email-masked]>
Date: Fri, 14 Sep 2001 10:57:43 -0700

Hi Denis,
    My interpretation is (4).

It is a bag of certificates that the recipient could find useful
to validate the request/response.

There may be some extraneous/irrelevant certificates, there might
not be all the certificates the client needs.

NOTE: IN THE CA DELEGATED TRUST MODEL FOR OCSP, THE RESPONDER MUST
BE DIRECTLY CERTIFIED BY THE CA - THERE MAY NOT BE CHAINING OF
ARBITRARY DEPTH I.E. IF CA1 CERTIFIES CA2, IT CAN'T CERTIFY
AN OCSP RESPONDER AND HAVE THAT TRUSTED AS A CA DELEGATED OCSP
RESPONDER FOR CA2.

Regards,
Ambarish

> Sent: Friday, September 14, 2001 9:52 AM
> To: David P. Kemp
> Cc: Pkix (E-mail)
> > 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."
> 
> 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: Ryan Hurst <[email-masked]>
Date: Fri, 14 Sep 2001 11:06:37 -0700

Denis --

I would say #5 :)

5) a sequence of (always) "useful" X.509 certificates
	
This allows for most cases to work; I do not see the benefit in restricting
the use of this attribute to a chain either. The only problem I see with
leaving its use generic is that there will be different uses of the
attribute, for that reason I would like to see a recommendation on its use;
possibly:

   BasicOCSPResponse       ::= SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

   The certs is field is a sequence X.509 certificates that may be useful
   to a client when verifying a response. When included it SHOULD contain
   all responder certificates that are associated with the signature on
   the response.

Ryan

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Friday, September 14, 2001 9:52 AM
To: David P. Kemp
Cc: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560

> 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

 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 ?

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.   

Denis

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 14 Sep 2001 11:57:43 -0700

Rich --

	Did I say that :), I am now embarrassed that I asked the question!
Yes that would be a cross-certification case.

As far as our "OCSP responder" product :) is concerned it depends on its
configuration...

Ryan

-----Original Message-----
From: Rich Salz [mailto:[email-masked]] 
Sent: Friday, September 14, 2001 10:46 AM
To: Ambarish Malpani
Cc: Dr S N Henson; Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560

It sure sounded like Ryan's note ssaid a single key with multiple CA's
verifying it, and the client finds the right verifier.  Or does your VA
product use a separate keypair for each CA it handles?

>issue of a single VA/OCSP Responder ...

You sure you want to risk losing your TM on "Validation Authority" by
consistently using it generically? :)
	/r$
-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 14 Sep 2001 11:56:50 -0700

Excerpt from the RFC to support Ambarish's note:

2.6  OCSP Signature Authority Delegation

   .... This certificate MUST be issued directly to the
   responder by the cognizant CA.

Ryan

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]] 
Sent: Friday, September 14, 2001 10:58 AM
To: 'Denis Pinkas'; David P. Kemp
Cc: Pkix (E-mail)
Subject: RE: Clarification request on RFC 2560

Hi Denis,

Regards,
Ambarish

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 14 Sep 2001 12:11:40 -0700

Steve --
	Excellent point!

Ryan

-----Original Message-----
From: Dr S N Henson [mailto:[email-masked]] 
Sent: Friday, September 14, 2001 11:21 AM
To: Pkix (E-mail)
Subject: Re: Clarification request on RFC 2560

Ryan Hurst wrote:
> 
> 
> Lets change the question, is there consensus that this is the correct
usage
> of the certs[] attribute?
> 

I would say that RFC2560 is unclear on this point. Some might take the
wording to suggest otherwise. For example twice in section 4.2.2.2 it
uses the term:

"the certificate used to validate the signature on the response".

The use of "the" might be taking to mean that there is only one such
certificate.

> I personally believe so; I do not see how one could deal with multiple ca
> responses without this methodology. Additionally I do not see any
downsides
> to this method.

Certainly without this methodology it can't be handled via a delegated
responder certificate. That would just leave the messy alternative of
local configuration.

Steve.