Subject: Comments on OCSP

From: [email-masked] (Peter Gutmann)
Date: Fri, 6 Nov 1998 20:34:40 (NZDT)

I've just spent the afternoon (trying to) implement this weeks version of 
OCSP.  There are some problems with this, here they are in rough order of 
severity:
 
- In the ResponseData there's a clash of tags between responseExtensions and 
  responderID.byName
 
- The certStatus is communicated by the tag on the encoded data rather than an 
  actual value, which means that unless you've got some hand-hacked ASN.1 
  decoder you can't tell what the status is because it's stripped out by the 
  decoding layer - you end up having to poke around to see what parts of the 
  XXXInfo you've wound up with and then try to guess the cert status from that.
  This should be:
 
   ...
   certStatus           ENUMERATED,
   certStatusInfo       CertStatusInfo OPTIONAL
   ...
 
   CertStatusInfo ::= SEQUENCE {
      [revocationTime etc]
      }
 
- The responseBytes are encoded using the dreaded OCTET STRING black hole, for 
  no good reason.  Instead of the current:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }
 
  it should be:
 
   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       ANY DEFINED BY responseType }
 
  (using the 1988 syntax, replace with the '93 version as required).
 
Finally, the entire set of PDU's are defined using an incredible amount of 
gratuitous and unnecessary tagging - were the authors being paid by the tag 
for this or something? :-).  You can strip out almost every tag in the spec 
without any adverse effects.  For example the OCSPRequest can be rewritten 
from:
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
 
to
 
   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature           Signature OPTIONAL }
 
   TBSRequest      ::=     SEQUENCE {
       version                     Version DEFAULT v1,
       requestorName       [0]     GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions           Extensions OPTIONAL }
 
   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs                   SEQUENCE OF Certificate OPTIONAL }
 
   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     Extensions OPTIONAL }
 
This is functionally completely identical to the previous version, but:
                        
 - It's easier to read
 - It's easier to encode
 - It's easier to decode
 - It's smaller when encoded
 
The same goes for the response format (with the exception of the responderID I 
can't find a single context-specific tag which is actually necessary).  Is 
there any reason why all the unnecessary tagging has to be there?
 
Peter.

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 06 Nov 1998 02:11:31 -0800

Hi Peter,
    Thanks for the comments - actually, this is a great review. Let
me try and justify the various points:

> - In the ResponseData there's a clash of tags between responseExtensions and

This clash shouldn't cause any problems in either encoding or decoding,
since the responderID and Extensions are separated by more than one
required fields.

Is this still an issue? Dan W. had actually pointed out the clash
between Version and ResponderID, which both had a tag of 0 and were
adjacent to each other. That was the reason for changing the tags.
However, I am not sure why the clash of non-adjacent tags is bad.

>    CertStatusInfo ::= SEQUENCE {

Actually, I thought this was a pretty neat idea (all the credit goes to
Slava for this one). I would think most people would encode a CHOICE as
a union and have something to distinguish which field of the union is
in use. Given that, it is unclear why we need to have a separate
certStatus field. Actually, I would think it make software more error
prone - what if the enumerated and the tag that tells you what the
field of the union is don't match?

It is possible, I suppose that one uses a void * instead of a union.
In that case, you would need to keep something telling you what the
type of the data is.

>   (using the 1988 syntax, replace with the '93 version as required).

Got my syntax from the definition of Extensions - "Monkey see, monkey
do", I suppose :-)

> there any reason why all the unnecessary tagging has to be there?

I think you are making 2 points here:
1. Why am I tagging things I didn't need to.
2. Why am I using explicit tagging.

Here are the reasons:
I actually like following simple rules that don't make me think too
much :-). Here are the two choices:
a. Tag only if you have two optional fields (actually only if they are
	adjacent (and of the same type))
b. Tag any time a field is optional.

Choice a. is more difficult to follow and more error prone as the spec
changes and people add/remove fields.

If you buy the previous argument, then, EXPLICIT tagging actually
helps me debug, because with IMPLICIT tagging, I lose the
actual type of the field and run something like your asn1dump,
or SSLeay's asn1parse doesn't actually give me a very useful
output.

I did assume that given that you already have the overhead of a
128 byte signature with the response, the few extra bytes
added by EXPLICIT encoding wouldn't be too bad.

Is that a reasonable argument, or could I have had my cake and
eaten it too and save some bytes all at the same time?

> Peter.

Regards,
Ambarish

-- 
---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833