Subject: Re: Matching CertIDs between OCSP requests and responses

From: [email-masked]
Date: Thu, 15 Mar 2001 16:15:13 +0000

Peter, all,

Yes, clearly clients must match certificate identifiers between request and
response.  However, the problem I was trying to highlight was just how this
matching should be performed.

Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't say that they MUST use it.  Suppose I send a request, in which my
CertID has used SHA1.  Suppose the responder then replies, but uses MD5 to
form the CertID term corresponding to the same certificate.  Then the
matching of the CertID term between request and response becomes less
trivial than a simple binary comparison.

As mentioned earlier, the complexity of matching certificate identifiers
between request and response increases in v2, where there are so many other
ways to identify a certificate.

The question is: can we trust the responder to use the same form of
certificate identifier as the client specified, so that the trivial binary
comparison of certificate identifier in the client is valid?

This problem is particularly acute in the situation where the responses are
pre-computed rather than being formatted on receipt of the request.

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                
                    (Peter Gutmann)        cc:     [email-masked]                           
                    Sent by:               Subject:     Re: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response
CertID
>terms will precisely match those from the request?

I would hope they do, otherwise there's a trivial attack which completely
defeats OCSP:

- You submit a request for a check of cert X (which has been revoked)
- What arrives at the CA is a request for a check of cert Y (which hasn't)
- You get back a response of "OK"

Unless you check the returned ID data there's no way you can detect this.
What
I'm doing is a binary compare of request and response ID data, if they
differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if
nonces
 aren't used, once I can determine experimentally how well-supported these
are
 in practice (the "no critical extensions" requirement in the spec doesn't
help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify [email-masked] and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:48:25 +0000

What I'm getting at is a slightly different issue with OCSP v2.  This has
several means for the request and response to identify the certificate:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}

However, there doesn't seem to be any condition requiring the response to
use the same method as was used in the request.  The request could use an
IssuerAndSerialNumber, and the response could then identify the same
certificate using CertID.  Should the response be forced to use the same
technique as the request?  How does this affect response pre-computation?

Jonathan

                    [email-masked]                                                            

                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it
doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID
has
>used SHA1.  Suppose the responder then replies, but uses MD5 to form the
>CertID term corresponding to the same certificate.  Then the matching of
the
>CertID term between request and response becomes less trivial than a
simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see
how
many servers you can break?

>ways to identify a certificate.

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for
this.

I'll do a bit of experimenting next week, but I'd be very surprised if a
binary
compare failed for any responder.

Peter.

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:55:32 +0000

I think that the ability to specify multiple certificates is useful, in
particular for validating a non-trivial certificate chain.  In this case,
it makes sense to trust the chain only as much as the least trusted
certificate in the chain.

However, the delegated OCSP signing model isn't ideally suited to
certificate chains - you have to use the trusted authority OCSP signing
model instead.  This subject has been discussed on this list previously.

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            
                    land.ac.nz             To:     [email-masked]                           
                    (Peter Gutmann)        cc:                                                 
                    Sent by:               Subject:     RE: Matching CertIDs between OCSP      
                    [email-masked]        requests and responses                              
                    land.ac.nz                                                                 

                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 

[email-masked]

>The idea of non-global errors is interesting, I hadn't thought about that.
It
>might be useful where multiple certificates are present in the request.

Is anyone (apart from Identrus, who do it for political/economic rather
than
technical reasons) doing this to any extent?  There is anecdotal evidence
which
suggests that implementors are using only one cert per query, having
multiple
certs per query is hideous in terms of handling responses (let's see now,
this
one is OK, this one isn't, we don't know about this one... no, the third
one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at
once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 16 Mar 2001 05:20:44 (NZDT)

>The idea of non-global errors is interesting, I hadn't thought about that. It

Is anyone (apart from Identrus, who do it for political/economic rather than
technical reasons) doing this to any extent?  There is anecdotal evidence which
suggests that implementors are using only one cert per query, having multiple
certs per query is hideous in terms of handling responses (let's see now, this
one is OK, this one isn't, we don't know about this one... no, the third one,
not the second one... no that one's OK, you want the one next to it... etc
etc).  Although my code supports the ability to query multiple certs at once, I
haven't enabled it because handling mixed responses is just too messy, it's
much, *much* easier to work with if you do it on the basis of "Is this cert
revoked or not?" rather than "Tell me whatever you can about this bundle of
stuff, and I'll try and figure out what's what from your response".

Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 15 Mar 2001 14:32:29 -0800

Peter, we do use multiple certs in a query for multiple reasons:

a. To query the status of a whole chain at a time

b. To query the status of all certs in something like an address
book, to figure out which certs that I have in my address book
are still good.

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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 9:21 PM
> To: [email-masked]
> Subject: RE: Matching CertIDs between OCSP requests and responses
> 
>

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 15 Mar 2001 11:56:18 -0800

Regards,
Ambarish

---

From: "Grant, Alistair" <[email-masked]>
Date: Sun, 18 Mar 2001 10:39:11 +1100

Hi Jonathan,

Do you happen to know when the signing model with multiple CertIDs was
discussed?

I am thinking about this at the moment, but don't remember any discussion on
the PKIX list.

Thanks very much.

Cheers,

Alistair Grant
Computer Associates
Development Manager, eTrust R&D
Phone:		+61 3 9825 5692
Mobile:		+61 408 565 080
E-Mail:		[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 16, 2001 3:56 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Matching CertIDs between OCSP requests and responses

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 16 Mar 2001 05:07:11 (NZDT)

[email-masked] writes:

>Another OCSP (v1) question:  Can a client assume that the OCSP response CertID

Unless you check the returned ID data there's no way you can detect this.  What
I'm doing is a binary compare of request and response ID data, if they differ I
don't trust the response.

(There's a second, slightly less trivial attack which you can perform if nonces
 aren't used, once I can determine experimentally how well-supported these are
 in practice (the "no critical extensions" requirement in the spec doesn't help
 much with this) I'll see if I can make them mandatory in my code).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 16 Mar 2001 05:31:04 (NZDT)

[email-masked] writes:

>Section 4.3 of OCSP v1 states that responders SHALL support SHA1 - it doesn't
>say that they MUST use it.  Suppose I send a request, in which my CertID has
>CertID term corresponding to the same certificate.  Then the matching of the
>CertID term between request and response becomes less trivial than a simple
>binary comparison.

Anecdotal evidence (that chap again) suggests that everyone uses SHA1
exclusively.  Have you tried submitting a request hashed with MD5 to see how
many servers you can break?

Yes, but they're all unique (there's only one way to encode an
issuerAndSerialNumber, certificate, etc), a binary compare should do for this.

I'll do a bit of experimenting next week, but I'd be very surprised if a binary
compare failed for any responder.

Peter.

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:15:13 +0000

Peter, all,

Regards,

Jonathan
---------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            

                    16/03/01 05:07                                                             
                    Please respond                                                             
                    to pgut001                                                                 

CertID

Peter.

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:55:32 +0000

Jonathan
----------------
Dr Jonathan Tuliani
www.symbian.com

                    [email-masked]                                                            

                    16/03/01 05:20                                                             
                    Please respond                                                             
                    to pgut001                                                                 

It

Peter.

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:48:25 +0000

ReqCert  ::= CHOICE {
   certID            CertID,

Jonathan

                    [email-masked]                                                            

                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 

doesn't
has
the
simple

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 16 Mar 2001 05:31:04 (NZDT)

Peter.

---

From: [email-masked]
Date: Thu, 15 Mar 2001 16:48:25 +0000

ReqCert  ::= CHOICE {
   certID            CertID,

Jonathan

                    [email-masked]                                                            

                    16/03/01 05:31                                                             
                    Please respond                                                             
                    to pgut001                                                                 

doesn't
has
the
simple

Peter.

---

From: [email-masked]
Date: Tue, 20 Mar 2001 16:40:13 +0000

Jeff, all,

I believe that if something is DER, then its components should also be.
However, I'm willing to be corrected if someone else wishes to comment.

You're right in your observations that people aren't as strict as they
might be in how they write the specifications.  I have certainly found the
phrasing in certain areas unclear or ambiguous.  This is also true of how
the specifications are then implemented - I've found several minor
transgressions of RFC 2456/2560 that simply required me to relax our code a
little.

On the whole, DER is what people are using, so you'd be best to stick to
that.  My advice would be that as far as is possible (and safe) you should
be strict in what you encode, and generous in what you decode.  And there
is no substitute for interoperability testing.

Jonathan
------------
Dr Jonathan Tuliani
www.symbian.com

                    Jeff Jacoby                                                                                       
                    <jjacoby@rsasec        To:     [email-masked]                                                  
                    urity.com>             cc:                                                                        
                                           Subject:     Re: Matching CertIDs between OCSP requests and responses      
                    20/03/01 16:17                                                                                    

Jonathan,

[some snippage]

Reading both 2560 and the draft for v2, I see this regarding DER
encoding:

 1. Before calculainting hashs and signatures DER is specified in
    various sections

 2. In section 4.1.1 Request Syntax,  aside from items noted in 1.
above,
    there is no other mention of a DER encoding requirment for requests
or
    any part of the request

 3. In section 4.2.1 ASN.1 Specification of the OCSP Response, there is
    an explicit statement that DER shall be used for encoding of
BasicOCSPResonse

 4. Appendix A OCSP over HTTP, there are explicit statements that DER is
to
    be used (but no use of "SHALL" or "MUST") for both request and
responses

On point 3 alone -- and this may show off my ignorance of ASN.1 -- does
saying
that BasicOCSPResponse must be DER encoded ALSO mean all subbordinate
components
must be DER encoded as well?

On points 2 and 4 together, it seems that if I use another transport
protocol
I'm allowed to encode my requests in BER.  Is this right?

Jeff