Should a CRL be required for an OCSP service provider to assert status.

So i ran into an interesting situation today that sparked a conversation.
Suppose we have a development CA that has issued 2 certificates.  The first
is a SSL webserver cert, and the second is the OCSP Signing certificate
allowing our OCSP service to assert status. The CA has NOT created or
published a CRL. The software we are researching allows a lot of
flexibility in how the ocsp database is created. One of the configuration
options is to compute the database based on a list of serial numbers that
we know the CA says has/will issue. So for example I know this CA has
issued the server cert (serial 0x12345) so I choose to compute 0x12345 as
good. I also choose to make the OCSP response this update value = to the
response creation time, as well as the validity to be a static 10 days from
the response creation. The vendor tool fails to create a database because a
CRL is not present. During my discussion with the vendor, they said,
although they could technically create a database without the CRL in this
case, they don't feel that they have the authority to do so.  But, on the
contrary, they also allow the OCSP service owner to perform "instant
revocation" which marks a serial as revoked regardless if the CA owner
revokes the serial, or publishes a CRL.  My initial thought is an OCSP
service should be able to assert any status as long as the CA has delegated
authority to the service via the OCSP Signing certificate.

Ok, with that whole semi organized info dump about what I know here are the
official questions.

*Q1: Should an OCSP service provider be able to assert a status of revoked
when the serial is not revoked on the CA.*



*Q2: Should an OCSP service provider be able to assert a status of good for
a truly valid issued certificate when no CRL has been created by the CA*
 I would like to know if their our any standards out there that provide
guidance on this subject.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix