Re: [pkix] Should a CRL be required for an OCSP service provider to assert status.

[Peter Rybár <[e-mail]>]

Dear Daniel,

 

You must provide also the correct time value in the thisUpdate OCSP field.

 

When the validations are expected in the online system, e.g. the system based on SSL/TLS, then the system uses directly or imaginary the value of acceptable calculated risk. http://www.dictionary.com/browse/calculated-risk

The calculated risk, in this case, is the interval between the time value (the present time in the online system) and the time value in thisUpdate field.

 

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

 

This case is already define in ISO/ITU-T X.509 as an authorization. 

See Clause 7.10  http://www.itu.int/itu-t/recommendations/rec.aspx?rec=X.509 

„This revocation and a notification of the revocation may be done directly by the same authority that issued the certificate, or indirectly by another authority duly authorized by the authority that issued the certificate.“

 

The trusted authorization is usually declared at a upper level.

E.g. in a globally accessible European Union trusted list. 

See http://ep.nbusr.sk/kca/tsl/tlX509XMLSchemaDocumentation.pdf 

 

- 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

This case is also already covered e.g. by European legislation where the CA store the certificates in the CA database and  the CA database contains also the certificate status.

OCSP response is directly created according to information from this database.

 

For more information see the document in the attachment.

 

The eIDAS Regulation (EU) No 910/2014 http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32014R0910 

 

Article 24(2) point (k): in case of qualified trust service providers issuing qualified certificates, establish and keep updated a certificate database. 

 

Article 24(3): If a qualified trust service provider issuing qualified certificates decides to revoke a certificate, it shall register such revocation in its certificate database and publish the revocation status of the certificate in a timely manner, and in any event within 24 hours after the receipt of the request. The revocation shall become effective immediately upon its publication.

 

Article 24(4): With regard to paragraph 3, qualified trust service providers issuing qualified certificates shall provide to any relying party information on the validity or revocation status of qualified certificates issued by them. This information shall be made available at least on a per certificate basis at any time and beyond the validity period of the certificate in an automated manner that is reliable, free of charge and efficient.

 

The OCSP response is already able to cover the requirements like "beyond the validity period of the certificate" with the one of the two already used OCSP response extensions in the real systems: 

•             CertHash OCSP single extension, see http://www.common-pki.org/uploads/media/Common-PKI_v2.0.pdf

•             ArchiveCutoff OCSP extension, see RFC 6960 https://tools.ietf.org/html/rfc6960#section-4.4.4

 

The CertHash - OCSP single extension is mandatory in some EU member states.

 

OCSP - CertHash is the hash value of the certificate whose status is returned by the OCSP response (Common PKI extensions CertHash (positive statement), Clause 3.1.2, Common PKI Specification V2.0). If this extension is found in the OCSP response, then the certificate status is known for OCSP and the hash value ensures the integrity by currently secure hash algorithm.

 

ITU-T/ISO standard for X.509 certificates and RFC 6960 define the rules for CRL and OCSP response. 

RFC 6960:

"

   thisUpdate -   The most recent time at which the status being indicated is known by the responder  to have been correct. 

   nextUpdate - The time at or before which newer information will be available about the status of the certificate.

   producedAt - The time at which the OCSP responder signed this response.

   revocationTime - The time at which the certificate was revoked or placed on hold. 

 

If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time.

"

 

Best regards,

Peter

 

 

From: pkix [mailto:[e-mail]] On Behalf Of daniel bryan
Sent: Wednesday, June 8, 2016 10:22 PM
To: [e-mail]
Subject: [pkix] 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.