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

[daniel bryan <[e-mail]>]

Thanks for such a detailed response. I believe i understand what your
saying, but I want to resay it just to make sure.


Point 1: The first point you say is that "This update" should be based on
the most recent time at which the status is known to be correct to the
responder. Suppose the following case. The CA makes the status known via a
CRL. It publishes a CRL june 9th at 12am UTC.  The next CRL will be
published 12 hours later (June 9th 12pm). The OCSP service is asked for the
status of this certificate june 9th at 6am.  It sounds like your saying the
proper response for the OCSP service to return in the this update field is
the time on the CRL (june 9th @12am) because we don't "know" if any
revocation took place between 12am and 6am, and we wont find out for 6 more
hours. We would still use jun 9th@6am for the "produced at" time, but not
"this update"  Am i understanding this point right?

Regarding Question 1: should the ocsp service be able to say revoked if the
CA hasnot/will not revoke the cert. It sounds like your saying yes. As long
as the CA has authorized the service to respond on it's behalf, it's ok if
the status of the CA database, is different from the ocsp service.

Regarding question 2: should the ocsp service be able to assert good.. It
sounds like your saying, it's ok for it to assert good, as long as it was
learned from an authorized source, for example, if the CA allows the ocsp
service to view the database of issued certs. But it is NOT ok for the OCSP
service to just say good, when it has no idea if the cert was issued or
valid.  This is also semi related to pre-computed databases.  Alot of OCSP
service software allows you to "assume" certs are good as long as they are
not on a CRL. for example, if the CA issued certs 0x1to 0x500 and only
revoked serial 0x100. the software allows you to assume good based on the
CRL. you might say that you want to assume 500 up, and 500 down as good. so
0x1 to 0x600 would be good (with the exception of the revoked 0x100) But in
reality, serials 501 - 600 have never been issued.  I can see the certhash
extension being of use here also. Overall, it sounds like your saying, it
is absolutely against standard to assume a cert is good, unless you have
been explicitly told by the CA that its been issued and is not revoked. Am
i understanding this right?



On Thu, Jun 9, 2016 at 9:29 AM Peter Rybár <[e-mail]> wrote:

> 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.
>