Subject: SCVP, OCSP-X and DCS

From: Denis Pinkas <[email-masked]>
Date: Mon, 06 Mar 2000 18:17:21 +0100

Ambarish made a nice presentation of OCSP and SCVP at the RSA
Conference. The OCSP document has expired and no discussion has
recently taken place about it. A revision is expected soon. The
expired version included a large section on open issues.

As far as I remember, it was requested to the various drafts editors
from DCS, OSCP-X and SCVP to meet together to come with a single
proposal. Apparently this has not happened yet, but this is still a
wish.

I provide the following comments, not specifically for SCVP but for
the "Son of SCVP, OSCP-X and DCS".

Note: Since I will be abroad for the remaining of the week, I will
not be able to answer until next week. Anyway, this mail may help to
progress the work.

Detailed comments

1. The structure of the document is not adequate. The ASN1 should
come upfront in section 3 so that it can be more easy to follow the
description. An ASN1 module should then be placed in an annex. 

2. The structure of the ASN1 response does not fit with the
structure of the ASN1 request, in particular when the ASN1 request
is about multiple certificates. The ASN1 request should be
restructured (see more detailed comments later).

3. The name TBSRequest is not explained. To Be Signed ? If it is,
the name is not correct, because the structure is not necessarily
signed.

4. In section 1.1 it said that "Untrusted severs can give client the
certificate chains needed for path validation". This contradicts the
fact that later on, in section 1.3 Open issues: "In this version of
spec., all responses must be signed". Such a response does not need
to be signed.

5. Section 3.15 is misnamed. The header is UsageID while the
description is " [It] specifies to the server the policy ID ... What
not call it "Policy ID" or ValidationPolicyID" ?

6. The section 3.16 should be deleted. This is a door opened to
proprietary implementations.

7. In section 3.17, two types of checks are mentioned. It is
proposed to have five types of checks instead:

  - Path validation to a trusted root,
  - Revocation status using CRLs for the leaf element,
  - Revocation status using OCSP for the leaf element,
  - Revocation status using CRLs all the way, except for the leaf
element,
  - Revocation status using OCSP all the way, except for the leaf
element,

It would be simpler and much shorter to define bits instead of
(long) OIDs.

8. In section 3.18, two information may be returned. It is proposed
to have five instead:

  - Certificate chain to a trusted root,
  - Proof of revocation status for the leaf element using CRLs,
  - Proof of revocation status for the leaf element using OCSP,
  - Proof of revocation status for CAs using CRLs all the way,
  - Proof of revocation status for CAs using OCSP all the way,

9. In section 3.19, it should be said that the default time is the
current time.

10. In section 3.19, it is said:" if the server doesn't have
historical information about that time, the information will be for
a time later than the ValidityTime." This does not work in general:
if the certificate has expired there is no more information
maintained in CRLs beyond the validity of the certificate and thus
the result will be "not revoked" instead of "revoked" ! This could
only work if that time is within the validity period of the
certificate. For the sake of simplicity, an error should be
returned. 

11. In section 3.21, the protocol should allow to specify a hash
algorithm, even if the default one is currently SHA-1.

12. Section 3.23 is about a "signature name". This item is not
needed and should be suppressed since the identifier of the
certificate's server should be present and signed anyway. 

13. Section 3.23 is about a KeyID. The KeyID should not be the hash
of a public key, but the certificate identifier together with the
hash of the certificate itself. 

14. In section 4.7 the time should not be Greenwich Mean Time, but
UTC (which happens to be equivalent to GMT).

15. Section 4.8 does not seem to make sense. Delete.

16. Section 5. As said earlier, the structure of the request does
not match with the structure of the response, which is more well
thought to support multiple responses. Without trying to make all
the necessary corrections and comments, hereafter are a few:

17. The request, if really able to support multiple certificates in
the request, should support for each certificate all the options.
This is not the case with the current proposal.

18. Under which circumstances should the request be signed or not
signed ?

19. Why is "Query" a CHOICE with a single choice, i.e. no choice !

20. The MAJOR item in the CertsQuery is usageID [4], which should
come upfront. A much better name would be ValidationPolicyID.

21. RevocationInfos should not be defined as an extension, but like
in CMS.

22. ConfigurationIdentifier should be deleted.

23. CertItem should be defined as:

CertItem::= SEQUENCE {
   certID   CertID,
   certHash CertHash,
}

This structure protects against a CA key compromise.

Denis

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 07 Mar 2000 01:53:21 +0100

> expired version included a large section on open issues.

I'd like very much to see added a new response status to the
Valid/Revoked/Unkown list: Suspended.

This issued was raised when writing about CSLs (Suspension Lists).
I do admit there is a way to implement it with extensions (as
suggested on the list), anyway I'd like to see the 'Suspended'
response added. Someone shares this point of view ??

C'you,

	Massimiliano Pala ([email-masked])